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ABSTRACT 


According to a 2010 Government Aeeountability Offiee (GAO) report, major system 
aequisitions within the Department of Defense (DOD) tend to be behind sehedule, over 
budget, and often fail to deliver at least some of the planned eapabilities. One area that 
ean signifieantly eontribute to suceessful implementation of systems engineering is the 
regular usage of management software tools and their continued evolution to better meet 
systems engineering needs. This thesis provides a detailed exploration of four eategories 
of available system engineering management tools: Model-Based Systems Engineering 
(MBSE), Produet Eife Cyele Management (PEM), Systems Engineering Environment 
(SEE), and Projeet Management software. Eaeh tool has numerous features that support 
sueeessful systems engineering. However, there does not seem to be a eonsolidated 
commereially available tool or system that allows for seamless management of 
systems engineering projeets aeross all of the proeess areas. Drawing upon these existing 
tools and the International Council on Systems Engineering (INCOSE) proeesses, this 
thesis derives a set of requirements for sueh a consolidated systems engineering 
management tool. This researeh can serve as the starting point for a follow-on effort to 
develop sueh a tool. 
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EXECUTIVE SUMMARY 


According to a 2010 GAO report, major system aequisitions within the Department of 
Defense (DOD) tend to be behind sehedule, over budget, and often fail to deliver at least 
some of the planned eapabilities (GAO 2010, under “Highlights”). With decreasing DOD 
budgets and increased oversight there is growing pressure to address these issues. In their 
2008 Report on Systemie Root Cause Analysis of Program Failures the National Defense 
Industrial Assoeiation (NDIA) “reeognize(d) that there is a strong relationship between 
diseiplined systems engineering and good management deeision making in the eritieal 
early states of an aequisition eyele” (NDIA 2008, 3). One area that ean signifieantly 
eontribute to sueeessful implementation of systems engineering is the regular usage of 
systems engineering management software tools and as updated to better meet systems 
engineering needs. This thesis explores the key eomponents of systems engineering 
management, eonducts a survey of existing software tools that ean be used to support 
systems engineering management, and proposes requirements for a tool that would 
improve systems engineering management. 

This thesis finds that although there are a variety of software produets available to 
support systems engineering management, they do not seamlessly integrate to support a 
systems engineering effort from beginning to end. This thesis reeommends that 
developing a single eonsolidated tool or a suite of integrated tools to support the systems 
engineering management effort would signifieantly benefit the systems engineering 
eommunity. And, in turn, it would signifieantly benefit the DOD in exeeuting highly 
eomplex systems engineering efforts. However, it seems that the DOD has not yet started 
adopting Systems Engineering Environment (SEE) types of tool sets. It would be 
advantageous for the DOD to put a foeus on moving in this direetion. This in turn eould 
motivate industry to spend more resources in produeing a product that could act as the 
glue for guiding a systems engineering effort. The starting point for developing sueh a 
produet is reeommended to be the set of International Couneil on Systems Engineering 
(INCOSE) or Defense Aequisition University (DAU) proeesses. 
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This thesis provides a survey of four different categories of software tools that 
could support systems engineering management. Each category is described and the 
benefits and challenges are discussed. The first category is Model-Based Systems 
Engineering (MBSE). It is a highly process-focused technique that parallels the systems 
engineering processes. INCOSE predicts that MBSE will be fully mature and ready for 
full adoption at the organizational level by 2020, and there are DOD efforts underway to 
embrace MBSE. The second category is Product Eife Cycle Management (PEM). It is a 
holistic approach for managing systems engineering efforts through the entire life cycle. 
The DOD is looking at PEM as a solution to help deal with significant complexity and to 
reduce costs. 

The third category is SEE. It is an integrated environment for executing systems 
engineering efforts throughout the life cycle. SEE seems to be a very promising concept 
for addressing the challenges of managing a systems engineering effort but unfortunately 
does not seem to have been able to gain a meaningful foothold within DOD. The final 
category is Project Management tools. It focuses on a range of tools that although do not 
directly relate to systems engineering, do have a number of features that would prove 
useful to any team and manager. 

All four categories of tools offer features of significant benefit to a Chief Systems 
Engineer (CSE). Some of these tools can also be used in combination to extend those 
benefits (such as MBSE and PEM). And the SEE concept presents a promising approach 
to having a central system through which the CSE can manage the systems engineering 
effort. However, there currently does not seem to be a consolidated commercially 
available tool or system that allows for seamless management of systems engineering 
projects across all of the process areas. 

Einally, a set of key features is listed and requirements are developed for a central 
tool that supports systems engineering management. The approach used is to start with 
the INCOSE systems engineering processes as the central guide for building such a tool. 
This approach supports a broad range of systems engineering efforts by allowing for 
significant tailoring. The requirements are derived from the activities and sub-activities 
described for each process. Several key stipulations are offered. Eirst, the management 



tool is intended to be a guide for the CSE and not a replaoement for activities and 
decisions that must still be made by humans. Second, the set of requirements is not an 
exhaustive set but is intended as a starting point. 

The envisioned systems engineering management tool would leverage the benefits 
of existing tools by either integrating with them or offering similar functionality. There 
are three areas where the tool would be especially beneficial. The first would be to 
provide a standardized approach to managing a systems engineering effort by guiding it 
from start to finish. This would help normalize for experience level of the CSE and would 
also reduce dependence on one or a few key individuals. The second benefit is added 
insight into progress and challenges for the CSE, management, and decision makers by 
captured real-time status of the project. The third benefit is more complete and reliable 
organizational knowledge transfer. 

There is significant room to further expand beyond the set of requirements 
developed in this thesis, and one improvement could be to obtain feedback from 
practicing CSEs. The next step would be to create a prototype systems engineering 
management tool that can be tested on a real project. 
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I. 


INTRODUCTION 


A. BACKGROUND 

According to a 2010 GAO report, major system aequisitions within the 
Department of Defense (DOD) tend to be behind sehedule, over budget, and often fail to 
deliver at least some of the planned eapabilities (GAO 2010, under “Highlights”). With 
deereasing DOD budgets there is growing pressure to address these issues. In their 2008 
Report on Systemie Root Cause Analysis of Program Failures, the National Defense 
Industrial Association (NDIA) “recognize(d) that there is a strong relationship between 
diseiplined systems engineering and good management deeision making in the eritieal 
early states of an aequisition cyele” (NDIA 2008, 3). One area that ean signifieantly 
eontribute to sueeessful implementation of systems engineering is the regular usage of 
systems engineering management software tools and their eontinued evolution to better 
meet systems engineering needs. This thesis will explore the key eomponents of systems 
engineering management, eonduet a survey of existing software tools that ean be used to 
support systems engineering management, and propose requirements for a tool that would 
faeilitate systems engineering management. 

B. RESEARCH QUESTIONS 

This thesis explores the three following questions. 

1. What are the key eomponents of systems engineering management? 

The first step of this study is to explore the key eomponents of systems 
engineering management. Systems engineering teaehes that before a solution ean be 
developed the underlying problem must be fully understood. The solution must then traee 
from this deeper understanding, thereby validating that the solution is indeed the eorreet 
one for the problem at hand. Therefore, when searehing for a way to improve the 
management of systems engineering efforts, it is eritieal to first explore what systems 
engineering management entails. 
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2. What software tools are available that could support systems engineering 
management? 

It is prudent to perform a survey of available tools that could support systems 
engineering management. The goal is to leverage and build upon existing solutions. 
Furthermore, an appropriate solution may already exist thereby leading to an 
endorsement of a particular tool category. Since there are numerous individual tools, the 
approach taken will be to explore tool categories and identify the general benefits and 
challenges for each category. 

3. What requirements would an ideal systems engineering management tool have? 

This final question explores the key features for a software tool to support 
systems engineering management. It builds upon the results of question one and is further 
informed by the results of question two. 

C. SYSTEMS ENGINEERING CHALLENGES 

In the early 1990s, the Air Force funded the Systems Engineering Concept 
Demonstration (SECD) to “demonstrate the concept of an advanced computer-based 
environment of integrated software tools and methods which supports the...systems life 
cycle” with the intent that “systems and specialty engineers can increase their 
productivity and effectiveness during the development, maintenance, and enhancement of 
military computer-based systems” (Comer and Rohde 1992, 3). This was “one of the first 
efforts to seriously address automation of the systems engineering process” (Comer and 
Rohde 1992, 4), motivated by the realization of both the importance and difficulty of the 
systems engineering role in complex projects. The study organized systems engineering 
activities into three categories: engineering, communication, and management. It then 
listed needs and problems in each category. The underlying theme supported the thesis 
that in each area there was a significant need for automated support. In the management 
category specifically, the need for automated support was identified for the areas of 
process management, program planning and management, and task management. The 
communication category lists automation needs in the areas of collaboration and 
coordination, boundary spanning, and joint work product development. 
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Computer technology has experienced tremendous growth since the SECD study 
and many systems engineering automation tools are now available. However, in a 2010 
report on the top systems engineering issues NDIA highlights lack of consistent use of 
the latest practices and tools in the systems engineering community as well as the need 
for continued improvement and optimization of these software tools (Table 1). This 
leaves the systems engineering community exposed to many of the same challenges as 
they faced during the time of the SECD study. 


Table 1. Top 2006 and 2010 Systems Engineering Issues (after NDIA 2010, 2). 


2006 Issue 

2010 Issue 

Key systems engineering practices known 
to be effective are not consistently applied 
across all phases of the program life cycle. 

Institutionalization of practices has shown 
value when adopted, but adoption tends to 
be spotty. 

Collaborative environments, including 
systems engineering tools, are inadequate 
to effectively execute systems engineering 
at the joint capability, systems of systems 
(SoS), and system levels. 

State of the practice techniques not widely 
utilized. 

Multiple tools are available but little 
guidance on preference exists. 


The report also highlights as one of the top five systems engineering issues of 
2010: “It is difficult to use currently available standard systems engineering tools early in 
the life cycle. In addition, many tools are not readily available and the engineers have not 
been trained in their use” (NDIA 2010, 6). 

These issues combine to tell the story of a practice that is quickly evolving but 
has not yet fully matured. Ideally, systems engineers would consistently leverage 
standardized processes that are supported by comprehensive and integrated support tools 
in order to repeatedly produce high-quality products. Getting to this point is as much a 
systems engineering management challenge as it is a technical one. The good news is that 
in many respects it is possible to address both the management and technical perspectives 
with the same tool, or integrated suite of tools. Although the focus of this study is to 
identify systems engineering management tool solutions, systems engineering is also a 

3 




technical discipline so the lines between management and technical are significantly 
blurred. This assertion is supported by the following from the Handbook of Systems 
Engineering and Management: “Systems engineering involves a technical part and a 
managerial part. That is, it requires making technical decisions and trade-offs while 
controlling and managing the efforts of different experts and teams from various 
disciplines” (Shenhar and Sauser 2009, 120). Therefore, the ideal systems engineering 
management tool solution would encompass both the management and technical aspects 
of systems engineering. 

D. BENEFITS TO SYSTEM ENGINEERING COMMUNITY 

This research provides several benefits to the systems engineering community. 
First, this study identifies and analyzes key components of system engineering 
management and thereby provides an additional reference for future work in this area. 
Second, this study researches and reviews various categories of software management 
tools that can be used for systems engineering management and provides the benefits and 
challenges of each category. This serves to provide an organized survey of the various 
options that can be leveraged independently or in concert with each other to support 
systems engineering management. Third, it builds upon the first two items to recommend 
requirements of a systems engineering management tool. This analysis can be used as a 
starting point to develop such a tool. 

E. SCOPE 

This thesis surveys existing systems engineering management software tools. 
It reviews the key components of systems engineering management and explores 
systems engineering processes. It researches what management products exist that could 
support systems engineering management and identify the benefits and challenges of 
these products. Finally, it develops a set of requirements for a systems engineering 
management software tool. This thesis concludes with a set of tool requirements. 
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F. METHODOLOGY 

Information on the key components of systems engineering management will be 
collected through literary research, online research, and personal experience. 

A list of currently available software categories that can be leveraged to support 
systems engineering management will be gathered through literary research, online 
research, and personal experience. Description of each product category, as well as the 
benefits and challenges, will be obtained through literary and online research as well as 
review of existing products in that category, when appropriate. 

A recommended list of systems engineering management tool requirements will 
be developed by the author, supported by information derived from the first two elements 
above as well as literary research, online research, and personal experience. 

G. STRUCTURE 

Chapter II Key Components for Systems Engineering Management: This chapter 
reviews the definition of systems engineering and highlight key management 
components. It then explores systems engineering processes. Finally, it looks at the 
typical systems engineering toolbox to identify the common tools that a systems engineer 
utilizes on a regular basis. 

Chapter III Survey of Management Tools: This chapter reviews the various 
categories of management software tools and identifies the benefits and challenges 
associated with each. It also discusses ongoing DOD initiatives related to these 
categories, as applicable. 

Chapter IV DOD Systems Engineering Management Tool Descriptions: This 
chapter describes the requirements development process for a systems engineering 
management software tool. It also highlights key features and benefits of such a tool. 

Chapter V Conclusion and Future Research: This chapter summarizes the research 
and results presented in the thesis. It also presents areas that have not been fully explored 
in this thesis that would benefit from additional research. 
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Appendix: The appendix lists the systems engineering management tool 
requirements, and show how eaeh requirement traees from the INCOSE systems 
engineering proeesses. 
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II. SYSTEMS ENGINEERING MANAGEMENT 


This chapter explores the first researeh: What are the key eomponents of systems 
engineering management? This helps lay the foundation for the remainder of the study. It 
does so by reviewing established systems engineering proeesses that form the eomerstone 
of systems engineering. Then it concludes with an exploration of the eommon software 
produets used by CSEs for produeing, gathering, and eontrolling information. 

A. SYSTEMS ENGINEERING 

Before exploring the systems engineering management proeess, it is neeessary to 
review the definition of systems engineering. The International Couneil on Systems 
Engineering (INCOSE), an authoritative body on systems engineering, defines systems 
engineering as follows: 

Systems Engineering is an interdisciplinary approach and means to enable 
the realization of sueeessful systems. It foeuses on defining customer 
needs and required funetionality early in the development cyele, 
doeumenting requirements, then proeeeding with design synthesis and 
system validation while eonsidering the eomplete problem: Operations, 

Cost & Schedule, Performanee, Training & Support, Test, Manufacturing, 
and Disposal. Systems Engineering integrates all the diseiplines and 
speeialty groups into a team effort forming a struetured development 
proeess that proeeeds from eoneept to produetion to operation. Systems 
Engineering considers both the business and the technieal needs of all 
eustomers with the goal of providing a quality produet that meets the user 
needs. (INCOSE 2004) 

Here, one sees the foeus on interdiseiplinary and teaming aspects. Systems engineering 

requires expertise from multiple domains brought together in just the right way 

to develop the appropriate solution to a problem. It naturally follows that good 

eommunieation is a key element for sueeess. The definition also points out that systems 

engineering requires a broad perspeetive of the problem versus foeusing on the pieees 

independently. This is a key consideration when looking at solutions for comprehensive 

management. Einally, the definition emphasizes a “struetured development proeess” as 

the glue for success. The next section will explore the specifics of this process—or rather 

the set of processes that allow the CSE to realize this end goal. 
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B. SYSTEMS ENGINEERING PROCESSES 


Processes contribute to a well-developed project structure and “High strueture 
reduees the risk regardless of technology complexity or team size” (Kendriek 2009, 58). 
Although following a process is good praetice in most undertakings regardless of 
complexity, it is especially important in helping navigate the eomplexities eneountered in 
systems engineering efforts. A good proeess provides the following advantages, as noted 
by Tom Kendriek in “Identifying and Managing Project Risk” (Kendrick 2009, 23): 

• better communications 

• less rework 

• lowered costs, reduced time 

• earlier identifieation of gaps and inadequate specifieations 

• fewer surprises 

• less ehaos and firefighting. 

These are all key eonsiderations in the systems engineering realm. Another important 
aspeet of a proeess is that it is repeatable and can therefore easily be applied to multiple 
efforts. This is the motivation for developing detailed proeesses and communicating them 
to the eommunity of practiee. This section will review established systems engineering 
proeesses by looking at two reputable sources, the INCOSE System Engineering 
Handbook and the Defense Aequisition Guidebook. 

I. INCOSE Processes 

INCOSE follows International Organization for Standardization (ISO)/ 
International Eleetrotechnical Commission (lEC) 15288:2008 and divides proeesses 
into two categories, teehnical and project (INCOSE 2011). The “Teehnical 
Proeesses... include stakeholder requirements definition, requirements analysis, 
arehiteetural design, implementation, integration, verification, transition, validation, 
operation, maintenance, and disposal” (INCOSE 2011, 2). Teehnieal Proeess definitions 
can be found in section 6.4 of (ISO/IEC 2008). 

According to (ISO/IEC 2008, 35) these teehnical processes “define the activities 
that enable organization and project functions to optimize the benefits and reduee the 
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risks that arise from technical decisions and actions.” In other words, they encompass the 
most critical technical components of systems engineering, making them the natural 
starting point when characterizing the key pieces of information a CSE needs access to in 
order to plan, manage, monitor, and make decisions. 

In addition to technical processes, INCOSE also follows the ISO/IEC 15288:2008 
project processes. The “Project Processes...include project planning, project assessment 
and control, decision management, risk management, configuration management, 
information management, and measurement” (INCOSE 2011, 2). Project Process 
definitions can be found in section 6.3 of (ISO/IEC 2008). 

These processes are critical to the overall success of the project. Unlike the 
technical processes, the CSE does not lead the project processes, but instead contributes 
to them (Zipes 2007, 32). Nevertheless, the CSE must carefully track each of these as 
they pertain to systems engineering to ensure that appropriate insight is provided to the 
management team. Therefore, these processes are also an important component of the 
CSE’s situational awareness. 

Another key difference is that unlike the technical processes that occur 
sequentially in the more common life cycle development models, project processes “may 
be invoked at any time in the life cycle” (ISO/IEC 2008). This necessitates a full 
understanding of all of the project processes from the beginning and requires mechanisms 
to capture appropriate information so that it can be tracked and provided when requested. 

2. Defense Acquisition University (DAU) Processes 

DAU follows a similar approach to INCOSE. Processes are divided into two 
areas, technical processes and technical management processes (DAU 2013). The DAU 
technical processes, along with the purpose for each as described by DAU, are listed in 
Table 2. 
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Table 2. DAU Technical Processes (after DAU 2013, section 4.3) 


Technical Processes 

Purpose 

Stakeholder Requirements Definition 
(DAU 2013, section 4.3.10) 

"...helps ensure each individual stakeholder's 
requirements, expectations, and perceived 
constraints are understood from the acquisition 
perspective."(DAU 2013, section 4.3.10) 

Requirements Analysis 
(DAU 2013, section 4.3.11) 

"...involves the decomposition of user needs...into 
clear, achievable, and verifiable highdevel 
requirements." (DAU 2013, section 4.3.11) 

Architecture Design 
(DAU 2013, section 4.3.12) 

"...allows the Program Manager and Systems Engineer 
to translate the outputs of the Stakeholder 
Requirements Definition and Requirements Analysis 
processes into alternative design solutions and 
establishes the architectural design of candidate 
solutions that may be found in a system model." 

(DAU 2013, section 4.3.12) 

Implementation 

(DAU 2013, section 4.3.13) 

"...provides a system that satisfies specified design 
and stakeholder performance requirements." (DAU 
2013, section 4.3.13) 

Integration 

(DAU 2013, section 4.3.14) 

"...systematically assemble lower4evel system 
elements into successively higherdevel system 
elements, iterative with verification until the system 
itself emerges." (DAU 2013, section 4.3.13) 

Verification 

(DAU 2013, section 4.3.15) 

"...provides evidence that the system or system 
element performs its intended functions and meets 
all performance requirements listed in the system 
performance specification and functional and 
allocated baselines." (DAU 2013, section 4.3.15) 

Validation 

(DAU 2013, section 4.3.16) 

"...provides objective evidence that the capability 
provided by the system complies with stakeholder 
performance requirements, achieving its use in its 
intended operational environment." (DAU 2013, 
section 4.3.16) 

Transition 

(DAU 2013, section 4.3.17) 

"...process applied to move any system element to 
the next level in the physical architecture. For the 
end-item system, it is the process to install and field 
the system to the user in the operational 
environment." (DAU 2013, section 4.3.17) 
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The list is very similar to the INCOSE technical processes. The only difference is 
that DAU omits “Operation,” “Maintenance,” and “Disposal.” Instead, it seems that DAU 
bins each of these within the “Transition” process. A mapping between the INCOSE and 
DAU technical processes is provided in Figure 1. 


INCOSE (Technical Processes) 
Stakeholder Requirements Definition < 

RequirementsAnatysis ■< 

Architeaural Design Implementatkxi -« 

Integration 

Verification 



DAU (Technical Processes) 
Stakeholder Requirements Definition 

RequirementsAnatysis 

Architeaure Design Implementation 

Integration 

Verification 

Validation 

Transition 


Figure 1. Mapping between INCOSE and DAU Technical Processes 

Next examined are the DAU Technical Management Processes, along with the 
purpose for each as described by DAU (Table 3). 
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Table 3. DAU Technical Management Processes (after DAU 2013, section 4.3) 


Technical Management Processes 

Purpose 

Technical Planning 
(DAU 2013, section 4.3.2) 

"...provides the Program Manager and Systems 

Engineer with a framework to accomplish the 
technical activities that collectively increase product 
maturity and knowledge and reduce technical risks." 
(DAU 2013, section 4.3.2) 

Decision Analysis 
(DAU 2013, section 4.3.3) 

"...transforms a broadly stated decision opportunity 
into a traceable, defendable, and actionable plan." 

(DAU 2013, section 4.3.3) 

Technical Assessment 
(DAU 2013, section 4.3.4) 

"...allows the Systems Engineer to compare achieved 
results against defined criteria to provide a fact-based 
understanding of the current level of product 
knowledge, technical maturity, program status, and 
technical risk." (DAU 2013, section 4.3.4) 

Requirements Management 
(DAU 2013, section 4.3.5) 

"...helps ensure delivery of capability that meets 
intended mission performance to the operational end 
user." (DAU 2013, section 4.3.5) 

Risk Management 
(DAU 2013, section 4.3.6) 

"...primary method of mitigating program 
uncertainties and is therefore critical to achieving 
cost, schedule, and performance goals at every stage 
of the life cycle." (DAU 2013, section 4.3.6) 

Configuration Management 
(DAU 2013, section 4.3.7) 

"...allows technical insight into all levels of the system 
design and is the principal methodology for 
establishing and maintaining consistency of a 
system's functional, performance, and physical 
attributes with its requirements, design, and 
operational information throughout the system's life 
cycle." (DAU 2013, section 4.3.7) 

Technical Data Management 
(DAU 2013, section 4.3.8) 

"...identifies, acquires, manages, maintains, and 
ensures access to the technical data and computer 
software required to manage and support a system 
throughout the acquisition life cycle." (DAU 2013, 
section 4.3.8) 

Interface Management 
(DAU 2013, section 4.3.9) 

"...ensure interface definition and compliance among 
the system elements, as well as with other systems." 
(DAU 2013, section 4.3.9) 


Here, one can see a slight divergence from the INCOSE approach. These 
processes are presented from the perspective of a systems engineer and “provide a 
consistent framework for managing technical activities and identifying the technical 
information and events critical to the success of the program” (DAU 2013). Conversely, 
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rNCOSE takes a management perspective when presenting Project Processes, relying on 
input versus leadership from systems engineering. Despite this, a first order mapping 
between the two sets of processes can still be proposed. Although the perspectives may 
be different the end goal of creating a systematic approach to manage the engineering 
effort and support the project as a whole is the same. A mapping between the INCOSE 
and DAU management processes is provided in Figure 2. This mapping is developed by 
the author but partially informed by Eori Zipes’ (2007, 23-26) presentation “Program 
Management vs. Systems Engineering: How different are they?” at the 10th Annual 
Systems Engineering Conference: 


INCOSE (Project Processes) 
Projea Planning 

Projea Assessment arxJ Control 

Decision Management 


Risk Management 
Configuration Management 
Information Management 
Measurement 



DAU (Technical Management Processes) 
Technical Planning 

Decision Analysis 

Tech n kal Assessm ent 


R eq u irements M a nag ement 
Risk Management 
Configuration Management 
Technical Data Management 
Interface Management 
Figure 2. Mapping between INCOSE and DAEf Management Processes 


Eori Zipes (2007, 22) provides a good visualization of the close relationship 
between DAU and INCOSE processes, as well as Project Management Body of 
Knowledge processes (Figure 3). The diagram, along with rest of the presentation, 
discusses the significant overlap between systems engineering and project management 
functions. 
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Figure 3. Process Overlap (from Zipes 2007, 22) 

C. SYSTEMS ENGINEERING TOOLBOX 

There are various software products that in one way or another support the 
systems engineering effort. Some are optimized to facilitate execution of one or more of 
the systems engineering processes, and others more generally support execution of a 
project and prove useful in managing a systems engineering effort. Table 4 is a 
representative list of tools that a CSE may utilize to some degree. 

The pros and cons of having a large selection of tools is well described; 

The good news is that many tools are available to assist the engineer to 
develop solution across a wide variety of system needs. The bad news is 
that there is a very large selection of tools, they are not well integrated, 
and they are often highly tailored for narrow applications. The result is a 
seemingly endless landscape of un-integrated tools, methods, views, and 
techniques for system development. (Montgomery, Carlson, and 
Quartuccio 2012, 12). 

The integration of information is where the real challenge rests. A presentation from an 
INCOSE Model-Based Systems Engineering (MBSE) workshop also highlights this 
challenge. It notes that the variety of tools is there but the need is for a set of tools that 
seamlessly covers the systems engineering Vee (Eigure 4). The goal is to have a single 
product or a set of products that can seamlessly support a systems engineering effort from 
beginning to end. 
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Table 4. CSE Toolbox 


Function 

SW Tool Examples 

E-mail 

Mierosoft Outlook, Gmail 

Spreadsheet 

Mierosoft Exeel 

Presentation 

Mierosoft PowerPoint 

Doeument 

Mierosoft Word, Adobe Aerobat 

Diagram/Elowehart 

Mierosoft Visio 

Computer-aided design 

(CAD) 

Solidworks, Autodesk AutoCAD 

Sehedule 

Mierosoft Projeet, Oraele Primavera 

Sehedule Assessment 

Booz Allen Hamilton Polaris, forProjeet 

Earned Value 

Deltek Open Plan/Cobra/wInsight, Primavera P6/Cost 

Management (EVM) 

Manager 

Simulation 

Mathworks MATLAB, Wolfram Mathematiea 

Requirements 

IBM RequisitePro, IBM DOORS, Viteeh CORE 

Information Management 

Mierosoft SharePoint, Top Vue 

Risk Management 

SwordAetiveRisk Aetive Risk Manager, PRC Risk Register 

Model-Based Systems 

Engineering (MBSE) 

Atego Artisan Studio, 3SE Cradle, Viteeh CORE 

Produet Eife Cyele 

Management (PEM) 

Siemens Teameenter, PTC Windehill 

Soeial Workflow 

Sparqlight, Asana 

Remote Collaboration 

Defense Conneet Online 

Enterprise Resouree 

Planning (ERP) 

SAP ERP, Oraele ERP 
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INCOSE. 


A Tools oriented View of the Vee - Example 

Ref: Airbus Defense and Space Company, F Autran 




We have 
many tools in 
our inventory 
ai ready. 

Do they fit 

together, 

seamlessiy? 



Does anyone 
have toois to 
seamlessiy 
cover the 
entire Vee? 


MBSE - Missing Link in digital Enterprise Strategy? by Prof. Dipl.-fng. Heinz Stoewer. M.Sc., iNCOSE iW. Los Angeles. Jan 2014 


Figure 4. Tools Oriented View of the System Engineering Vee 

(from Heinz 2014) 


D. SUMMARY 

In this chapter, the key components of systems engineering management are 
explored. This is done by first reviewing established systems engineering processes from 
the perspectives of INCOSE and DAU. It is shown that both are organized by technical 
and management processes, and are similar. Then common software products used by 
CSEs for producing, gathering, and controlling information are identified. It is shown that 
although there are a variety of products available, they do not seamlessly integrate to 
support a systems engineering effort from beginning to end. 
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III. SURVEY OF MANAGEMENT TOOLS 


This chapter provides a survey of the different types of software tools that eould 
support systems engineering management. It looks into eategories of tool and identifies 
the key features. It then lists the benefits and challenges. The eategories that are be 
explored inelude MBSE, PLM, Systems Engineering Environment (SEE), and Projeet 
Management. Additional attention is provided to MBSE and PEM as there are ongoing 
initiatives within the DOD that are pushing both to the forefront. 

A. MODEL-BASED SYSTEMS ENGINEERING 

MBSE is defined as a “formalized applieation of modeling to support system 
requirements, design, analysis, verifieation, and validation aetivities beginning in the 
eoneeptual design phase and eontinuing throughout the development and later life eyele 
phases” (Eriedenthal, Greigo, and Sampson 2007, 5). The highly proeess-foeused nature 
of this teehnique parallels the systems engineering proeesses discussed in Chapter II. 
MBSE does this by providing clear traceability between the produets assoeiated with 
eaeh proeess. MBSE “enhanees specifieation and design quality, reuse of system 
speeification and design artifacts, and communications among the development team” 
(Eriedenthal, Moore, and Steiner 2012, 15). This foeus on higher quality, reduetion of 
rework, and improved eommunieations, as well as the proeess driven approaeh, makes 
MBSE a powerful tool to support systems engineering management. Several MBSE 
produets inelude Atego Artisan Studio, No Magie MagieDraw, and 3SE Cradle. 

The benefits of MBSE are numerous. INCOSE eompiled the following list of 
benefits for a MBSE foeused workshop (Eriedenthal, Greigo, and Sampson 2007, 7): 

• improved eommunieations 

• inereased ability to manage system eomplexity 

• improved produet quality 

• enhaneed knowledge eapture 

• improved ability to teaeh and learn systems engineering fundamentals. 
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Management is explicitly identified as a benefit. Communications is also 
identified and is a key element of successful management. Improved product quality is 
the primary goal of good management. The others are very desirable features at the 
organizational level, as well as for the community of practice. 

An alternate list of benefits is provided by Vitech Corporation, one of the leading 
MBSE product developers (Vitech Corp 2011, 112-115); 

• enhanced communication 

• reduced development risk 

• improved quality 

• increased productivity 

• increased scope 

• provides a structure to capture and communicate all aspects of the system 

• based upon the language of the systems engineer 

• contains and enforces the integrity of the system model 

• latest engineering is available to the entire project team. 

Communication and quality appear again on this list. Risk and scope are 
identified as well, both key elements that must be carefully managed for success. 
Increased productivity hints at a system that allows clear definition of work products and 
accountability for ensuring that work is done effectively and on schedule. MBSE is also 
designed with the systems engineering environment in mind and therefore has the benefit 
that it does not need to be tailored from another industry. The remaining benefits 
reinforce the organization and communication of information to provide a holistic view 
of the project in real time. 

In a report on the state of Model-Based Engineering (MBE), NDIA has shown 
how MBE benefits map to the DOD Acquisition Eife Cycle (Eigure 5). It is clear that 
there are very significant benefits at each phase that would directly or indirectly effect 
cost, schedule, and performance. The report also notes that the advantages gained in the 
early phases also have meaningful carry over to later phases. 
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MBE Benefits Across the Acquisition Life Cycle 


■ More complete evaluation of trade 
space [S. Bo«ng787] 

• Improved communications across 
stakeholders [s. a] 

•Earlier evaluation of manufacturing 
feasibility | 2 | 


• Rapidly evaluate changing threats and explore 
solution space (8] 

• Design Reuse [6.7] 

• Lower costs with complex product families [S] 


• Reduced manufacturing related 
costs and schedule i 
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• Improved requirements ( 3 , 4 . 6 . 7] 

• Earlier risk identification and 
mitigation (2.4. 7] 

• Early evaluation of manufacturing 
processes ( 2 ] 

•More complete evaluation of trade 
space (8. Boemg 787] 


• Earlier risk identification and mitigation ( 2 .4.7] 

• Concurrent and collaborative engineering ( 2 .3. 

«.n 

• Reduced defects and re-work costs (i. 3.4.7]) 

• Accelerated development schedule | 1 . s. 7] 

• Improved system and software reliability and 
quality (6.7.8] 

• Design reuse (s. 7]ll 


Figure 5. MBE Benefits aeross the Aequisition Life Cyele 

(from NDIA 2011, 16) 


MBSE also has some ehallenges. A white paper developed to promote the eoneept 
of System Definition-Enabled Acquisition (SDEA) faults the current state of MBSE tools 
as “individually inadequate to solve the total engineering problem” (Montgomery, 
Carlson, and Quartuccio 2012, 17). The perspective presented is that MBSE has not yet 
reached an appropriate level of maturity to be the one-stop solution to systems 
engineering development and management. This is echoed in various other publications 
and forums, including at the MBSE INCOSE workshop, where two specific challenges 
are identified. 

The first challenge is that the current state of MBSE lacks good 
“integration/interaction with the more ‘soft’ (human economics and social/environment 
based) elements of systems” (Heinz 2014, 28). The presentation goes on to explain 
that MBSE must “deal with science and art components of complex systems by also 
providing decision analysis support to PMs and other policy/decision makers” (Heinz 
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2014, 22). This hints at the need for full integration between engineering and 
management. In order to beeome a eomplete systems engineering solution, MBSE must 
ineorporate the management elements along with the teehnieal to ensure the CSE ean 
fully exeeute projeet planning and eontrol, and traek data that must be fed up the ehain to 
support the Projeet Management team. The seeond ehallenge is that “MBSE must strive 
to beeome seamless plug & play in terms of vertieal and horizontal navigation between 
different system levels and system eonstituents” (Heinz 2014, 28). Currently, MBSE is 
just another part of the systems engineering toolbox and Heinz (2014) notes that this 
requires additional integration. 

There are ongoing efforts to address these ehallenges. Eor example, an evolving 
produet ealled Systems Eifeeyele Management (SEIM) ereated by InterCAX attempts to 
fill the “gaps in eurrent state-of-the-art eommereial tools for design and analysis of 
eomplex systems” (Bajaj et al. 2011, 2) by working with what InterCAX ealls the Total 
System Model (TSM). InterCAX deseribes SLIM as a “eollaborative, model-based 
systems engineering workspaee for realizing next-generation eomplex systems” (Bajaj et 
al. 2011, 1). SLIM aets as a plug-in to existing MBSE produets and adds the funetionality 
to integrate with eommon systems engineering software produets. This integration is not 
only for teehnieal tools, but also ineludes management tools. Eigure 6 shows this 
integration to other funetional areas and software produets. The eonneetivity with PLM is 
also signifieant. PLM is gaining a lot of momentum as a management teehnique for 
eomplex projeets and will be diseussed in the next seetion. 
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System Lifecycle Management (SLIM) 

Enabling Model-Based Systems Engineering 

Primavera, MS Project, Windchill ProjectLink and PPMLink, 



Figure 6. SLIM Concept Diagram (from Intercax 2015) 


As another example, Lockheed Martin is attempting to address these challenges 
by extending the capabilities of MBSE “to support integration across discipline lines” 
(Oster 2013, 8) including management and customer decision support. Lockheed Martin 
is employing custom in-house scripts to execute this effort, facilitated by built-in 
capabilities of existing MBSE products. The objective is to create what Eockheed Martin 
calls the “model-based program execution” environment (Oster 2013, 12). Integration 
with PEM, as well as Product Data Management (PDM), is again highlighted as a 
capability multiplier. Beyond the immediate project, Lockheed Martin suggests that 
these models can be used to facilitate planning, development, and management of 
future systems. 
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INCOSE has created an MBSE Roadmap that shows the path towards full 
aeoeptanee of the MBSE approaeh (Eigure 6). This roadmap aeknowledges the 
previously identified ehallenges and the need for maturation of MBSE products. It 
predicts that MBSE will be fully mature and ready for full adoption at the organizational 
level by 2020. 


INCOSE MBSE Roadmap 



2010 2020 2025 

MBSE - Missing Link in digital Enterprise Strategy? by Prof. Dipl.-Ing. Heinz Stoewer, M.Sc., INCOSE IW. Los Angeles, Jan 2014 

Eigure 7. INCOSE MBSE Roadmap (from Heinz 2014, 27) 

The DOD has recognized the importance of MBSE, and has created an action in 
their Acquisition M&S Master Plan (AMSMP) to “Promote model-based systems 
engineering (MBSE) and M&S-enabled eollaborative engineering environments” 
(DOD 2006, 11). In this same doeument, the DOD aeknowledges the growing importanee 
of MBSE oiling the INCOSE Roadmap, growing industry aeoeptanee, and NDIA 
presentations (Hollenbaoh 2009, 12). In a separate aotion, the AMSMP proposes to 
“support development of open oommeroial and non-proprietary standards for (model- 
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based) systems engineering” (Hollenbaeh 2009, 19), with the goal of assessing for the 
purpose of implementation within the DOD. 

The MBSE eommunity of praetiee has also reeognized the importanee of tailoring 
MBSE produets to the DOD. The Objeet Management Group (OMG) has developed the 
Unified Modeling Eanguage (UME) 2 standard in order to “enable praetitioners to 
express Department of Defense Arehitecture Eramework (DODAE) and Ministry of 
Defenee Architeeture Eramework (MODAE) model elements and organize them in a set 
of speeified viewpoints and views that support the specific needs of stakeholders in the 
U.S. Department of Defense and the United Kingdom Department of Defence” (OMG 
2012, 3). 

As a specific example of embracing MBSE within the DOD, Defense Information 
Systems Agency (DISA) has piloted several projects using MBSE. It is currently in the 
process of transitioning all projects to be supported by MBSE and updating internal 
systems engineering processes. It is also training its personnel in MBSE. (Okon and 
Gedo, 9). 

B. PRODUCT LIFE CYCLE MANAGEMENT 

Produce Eife Cycle Management (PEM) is defined as “a systematic, controlled 
concept for managing and developing products and product related information” 
(Saaksvuori and Immonen 2008, 3). It is “a holistic concept developed to manage a 
product and its life cycle including not only items, documents, and Bill of Materials 
(BOMs), but also analysis results, test specifications, environmental component 
information, quality standards, engineering requirements, change orders, manufacturing 
procedures, product performance information, components suppliers, and so forth” 
(Saaksvuori and Immonen 2008, 2) and includes “workflow, program management, and 
project control features that standardize, automate, and speed up product management 
operations” (Saaksvuori and Immonen 2008, 2). It is immediately clear from the 
definition that PEM can serve as a valuable tool for helping manage systems engineering 
efforts. Although PEM is not a specific software but instead “a business approach that 
can align and increase the efficiency and effectiveness of activities” (Schindler 2010, 15), 
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software is a necessary and major component. Therefore, this analysis will focus on PLM 
software. Explicit benefits and challenges will be described next. Several PLM products 
include IBM Collaborative Life Cycle Management, Siemens Teamcenter, and PTC 
Windchill. 

The website PLM Info provides the following list of PLM software benefits: 

• Easter time-to-market 

• Improved cycle times 

• Lewer Errors 

• Less scrap & rework 

• Greater productivity 

• Greater Design efficiency 

• Better product quality 

• Decreased cost of new product introduction 

• Insight into critical processes 

• Better reporting and analytics 

• Standards and regulatory compliance 

• Improved design review and approval processes 

• Improved communication 

• Reduced product cost and greater profitability 

• Better resource utilization 

• Improved integration and communication with extended supply chain. 

(PLM Info 2011). 

All of these are desirable from a management standpoint. The three main 
considerations of management—cost, schedule, and performance—are represented 
throughout. Communication is highlighted, as well as resource utilization and 
productivity, all-important components of effectively leading a technical team. Design 
review and approval is highlighted as well—a key consideration in systems engineering. 
Also highlighted is better reporting and analytics. The promise is that by ensuring a 
single common source of data more accurate and timely reports can be generated, and 
decision makers can be better informed. 
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In a separate list, John Stark Associates provides the top ten business reasons for 
implementing PLM (John Stark Associates and SofTech 2007). 

1. Get product data under control—Product development is messy; clean it 
up. 

2. Automate product-related processes with workflow for increased 
productivity—Get rid of the stop-lights. 

3. Re-engineer product-related processes—Check for value added and 
streamline. 

4. Reduce product time to market with better application integration— 
Connect your islands of automation. 

5. Develop the right product—Listen to the voice of the customer. 

6. Collaboratively develop the best product—Maximize resources, local and 
global, internal and external. 

7. Information reuse—avoid reinventing the wheel. 

8. Increase mature product revenues—Listen to the voice of the product. 

9. Implement a global product strategy with PLM—Maximize revenues with 
localized products. 

10. Improve product visibility—Manage more effectively with PLM 
information. 

Stark expands on item 3 by stating “PLM brings together previously separate and 
independent processes in an integrated process architecture” (John Stark Associates and 
SofTech 2007, 3). This lends well to systems engineering considering its process-heavy 
nature described in Chapter IT The capability to correlate these processes and track 
interdependencies is critical to success. 

Items 4, 7, and 10 focus on gathering, accessing, connecting, utilizing, and 
displaying data. Information is often recorded on an independent system, and buried so 
deep that it is difficult to locate, or may have multiple versions and formats floating 
around. Saaksvuori and Immonen (2008, 94) cite a Coopers & Lybrand study showing 
that engineers spend 24% of their time sharing and retrieving information, 21% redoing 
work, and 14% in meetings largely focused on sharing information. This shows there is a 
significant opportunity to improve efficiency by integrating applications and supporting 
reuse—two strengths of PLM systems. Another organizational level advantage stemming 
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from this improved control of data is “realized when lessons learned from the first 
generation are applied to all subsequent generations” (Schindler 2010, 17). A system 
engineering manager would significantly benefit during project startup as well as all 
future phases from such a data repository of previous work, best practices, and lessons 
learned. 

There are also a number of challenges associated with PLM. The following is a 
list of challenges presented at a “Beyond PLM” panel discussion at the Aras Community 
Events International conference in 2011 (Shilovitsky 2011, 6). 

• Cost of implementation is too high. 

• Cost of change is skyrocketing. 

• New platforms need to be validated. 

• Customers is [j'/c] demanding vertical solution. 

• PLM without PLM is getting some votes. 

Additionally, PLM software can significantly “burden [the] organization and people” 
(Shilovitsky 2011b). There remain a number of challenges related to full integration of 
PLM software that need to be addressed. 

A study by CIMdata, which claims to be the leader in PLM education, research, 
and strategic management consulting, explored the results that the Aerospace and 
Defense Industry was seeing from implementing PLM. The research showed that despite 
heavy PLM investment there were, “with only a few exceptions, uninspiring results” 
(CIMdata 2013, I). The study identified two groups: Followers, making up the majority 
and receiving little value from PLM, and Leaders, making up the minority and receiving 
significant value. Figure 8 shows how each of these groups viewed the importance of 
various challenges to the success of implementing PLM in their organizations. 
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Figure 8. Importance of Challenges to success of implementing PLM in 
organization, divided among leaders and followers 
(from CIMdata 2013, 9) 
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The study highlighted that those organizations seeing little value from their PLM 
solution found the biggest challenge to be processes and functional overlap with other 
existing enterprise tools. In contrast, those receiving significant value out of PLM found 
the biggest challenge to be the culture within, and standardization across, the 
organization. These, along with the other challenges listed, can all be considered standard 
challenges when implementing any new system, especially a new systems that is 
expensive, enterprise-wide, and significantly affects the way business is done. 

The DOD is looking to PLM as one of the solutions to deal with “ever-more 
complex development and support environment...rapidly evolving technologies and 
threats... [and] higher dependence upon fast-moving commercial technologies”(Borek 
2008, 22). The same source concludes that “PLM is a DOD priority” (Borek 2008, 23). 
There is a specific Integrated Data Environment requirement in the DOD 5000.02 and the 
Defense Acquisition Guide (DAG) explicitly advocates for an Integrated Data 
Environment (IDE)/PLM system as part of the systems engineering Technical Data 
Management Process (DAU 2013). 

In response to this push from the DOD the Navy’s Program Executive Office 
(PEO) Integrated Warfare Systems (IWS) is developing the Enterprise Product Life 
Cycle Management Integrated Data Environment (ePLM IDE) (Marshall and Murphy 
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2011). This solution “bridges the gap between the engineering product development and 
life-cycle product support worlds with a robust ‘enabling’ environment by leveraging a 
suite of COTS PLM technologies” (Marshall and Murphy 2011, 6). Figure 9 shows the 
conceptual architecture. It shows ePLM IDE filling a central role in systems engineering 
management, collaboration, and decision support as it interfaces with systems 
engineering tools as well as other common tools and products. To further support this 
initiative, “NAVSEA and DISA have established a Partnership Portfolio allowing for 
COSTCO pricing” (Smith 2011, 4). This should help overcome two significant 
challenges: high cost of PEM products, and multiple instantiations of IDE/PLM solutions 
where a single enterprise solution would be more economical and provide greater 
capabilities (Smith 2011). 
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ePEM IDE Vision Architecture (from Marshall and Murphy 2011, 5) 
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C. SYSTEMS ENGINEERING ENVIRONMENT 

The complexity of systems engineering is driving the industry to create an 
integrated environment for executing a systems engineering effort throughout the life 
cycle. There does not seem to be an industry standard term for these integrated 
environments, but one common term often used by INCOSE and product developers such 
as Eclipse and Holagent is Systems Engineering Environment (SEE). Eclipse has 
developed the Open Systems Engineering Environment (OSEE) and has provided the 
following definition, which does a good job summarizing the purpose of a SEE. 

The Open System Engineering Environment (OSEE) project provides a 
tightly integrated environment supporting lean principles across a 
product’s full life-cycle in the context of an overall systems engineering 
approach. The system captures project data into a common user-defined 
data model providing bidirectional traceability, project health reporting, 
status, and metrics which seamlessly combine to form a coherent, accurate 
view of a project in real-time. By building on top of this data model, 

OSEE has been architected to provide an all-in-one solution to 
configuration management, requirements management, testing, validation, 
and project management. All of these work together to help an 
organization achieve lean objectives by reducing management activities, 
eliminating data duplication, reducing cycle-time through streamlined 
processes, and improving overall product quality through work flow 
standardization and early defect detection. (Eclipse 2013) 

INCOSE has also focused on building a CONOPS and set of requirements (both 
currently unpublished and in draft) for what it terms the Integrated Systems Engineering 
Environment (ISEE). The following definition is from a draft ISEE overview document 
being developed by the INCOSE Tools Interoperability and Integration Working Group 
ISEE (also unpublished and in draft), and reproduced here by permission of the author. 

the purpose of the Integrated Systems Engineering Environment (ISEE) is 
to create the computer-aided setting which enables the engineering teams 
to perform the major functions of Systems Engineering encompassing the 
entire program life cycle including the management, organization, and 
technical aspects of systems engineering...The ISEE will eventually 
address interfaces to other tool environments supporting other facets of 
program development. (Nation 2004, 1) 
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Figure 9, reproduced here by permission of the author, provides an overview of 
what would be part of ISEE, as well as external interfaces. 




Figure 10. ISEE Eunctions and Interfaces (from Nallon 2004, 2) 


The key message in both of these definitions is that the goal of SEE is to capture 
all systems engineering efforts and interfaces in a comprehensive and cohesive fashion. 
This would allow the CSE to manage ongoing work while planning for the entire product 
life-cycle. Several SEE products include OSEE, SSL Cradle, and Holagent RDD-100. 

Eclipse, the OSEE developer, offers up the following benefits of an SEE (Eclipse 

2014): 

• support for all engineering aspects (requirements, code, test, project 
management) 

• tightly integrated toolset 

• collaborative solution 

• consistent user interface across engineering areas 

• phased approach for development and extension 

• processes integrated into toolset 


decreased cost of all stages of the development life cycle. 
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All of these support systems engineering management. In fact, management of the 
systems engineering effort is explicitly included as part of the SEE. The integration of 
processes into the toolset is also a major benefit from the management perspective. Since 
systems engineering management is focused on executing and overseeing specific 
processes, having those already built into the tool increases the probability of success. 
Einally, SEE improves collaboration across all aspects of systems engineering that can 
significantly reduce miscommunication and rework, both major obstacles to success as 
seen in the previous section. 

Two additional benefits are worth noting. The first is that the SEE lends itself 
well to creating integrated dashboard views. These views are geared to quickly extract 
relevant information and can be customized as needed. This is especially relevant for 
systems engineering management since the CSE needs to keep track of the big picture on 
a regular basis and in real-time. Since the SEE tracks all aspects of the ongoing systems 
engineering effort, as well as the interfaces, it should have sufficient data to build 
appropriate dashboard views. As an example, 3SE Cradle allows for customized 
dashboard views by defining key performance indicators and setting thresholds (Eigure 
11). According to 3SE “This allows managers to manage by exception, so that they can 
quickly assess the state of the project” (3SE 2015). 
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Figure 11. 3SL Cradle Dashboard Customization (from SSL 2015) 

The seeond additional benefit is that the SEE ean be developed to allow for 
integration with existing tools. This allows the systems engineering team to utilize the 
preferred tool for a specific function and ensure that the data is also captured within the 
SEE to maintain big picture awareness. SSL Cradle shows this integration of tools in 
Eigure 12. One thing to notice is that Cradle interfaces with MBSE and PLM products so 
that all three of these powerful tools can be used in unison. 
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Figure 12. SSL Cradle Tool Integration (from SSL 2015) 


There are a number of ehallenges assoeiated with the SEE. One ehallenge is that 
due to the large array of projeets it is not possible to build a one-size-fits-all produet. 
Therefore, although SEE is supposed to be a “one stop shop” it is unlikely that an SEE 
produet out of the box will eontain all the necessary capabilities to make this possible. 
Therefore, additional work will be required to fill in the gaps. Eortunately, some SEE 
developers are taking this into account by providing the capability to extend the existing 
toolset for a particular application. Eor example, “OSEE contains an Eclipse extension 
point that allows features to be added to OSEE without having to rebuild the application” 
(Eclipse 2010). Therefore, the capability to customize the SEE for a specific project 
does exist. 

A second challenge is related to tool integration. As mentioned earlier, SEE 
depends on the ability to integrate with existing tools. If a specific tool is required for a 
project and the SEE product does not interface with it that would necessitate either 
spending significant money to integrate the tool or to leave that tool as stand-alone 
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product thereby losing some of the advantage of the SEE. In order to help address this 
ehallenge, the ISO I0303-AP233 was developed to standardize “representation of 
systems engineering data” (ISO 2012). That is a big step toward helping to build 
integrated tools but is merely the first step and requires tool manufacturers to adopt and 
utilize the standard in their development. 

Unfortunately, it appears that SEE has not been able to gain a meaningful 
foothold within DOD. The only publieally available evidence of SEE implementation 
within the DOD that the author has loeated is the use of RDD-100 within the Navy 
Theater Wide Theater Ballistie Missile Defense (NTW TBMD) Program (Hyer and Jones 
2000). Eor this program the ISEE database was segmented into five proeess areas 
(requirements, funetional behavior, physieal arehiteeture, verifieation methodology, and 
eost) whieh were linked together to allow full traeeability (Hyer and Jones 2000). And 
eventually “a strong eornerstone was established by the efforts to establish the 
requirements in the database and produee a series of reports, traeeability matriees, and.. .a 
eopy of the Systems Requirements Doeument” (Hyer and Jones 2000). However, no 
further evidenee eould be found of the ultimate sueeess of this or any similar DOD efforts 
whieh leads the author to believe that establishment of a SEE eapability within the DOD 
has not yet been sueeessful. 

D. PROJECT MANAGEMENT TOOLS 

The first three eategories ineluded either systems engineering speeifie tools or 
those that are very elosely tied to systems engineering. This last eategory will focus on a 
range of tools that, although they do not direetly relate to systems engineering, have a 
number of features that would prove useful to any team and manager. They eome from 
two eategories: projeet management software and soeial workflow software. Although 
these are distinet eategories there is so mueh feature overlap that for the purposes of this 
study we will treat them together. In this eategory, this focus will be on the benefits and 
not on the ehallenges. 
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Several products in this category include Kenesto, Sparqlight, Asana, AtTask, 
Base Camp, Red Mine, Deltek’s Axium, and Logic Software’s Easy Projects. Some of 
the key features offered by Kenesto (Kenesto 2014) are: 

• project workspaces 

• dashboards and reports 

• document management and vaulting 

• cloud document editing 

• flexible workflow management 

• task management and execution 

• drawing and document view and mark-up 

• enterprise-class file synchronization 

• forms and data management 

• data hierarchies. 

Task management, dashboards, and workspaces will be addressed in more detail. 
A common approach for task management seems to be to assign ad-hoc tasking at regular 
meetings or over email and then wait and hope that this tasking is both understood and 
fully completed by the required due date. This can often lead to misunderstandings and 
delays. With the size and complexity of most systems engineering efforts, tasking needs 
to be formalized to a great extent to be consistently successful. A tasking software 
solution goes a long way towards accomplishing these objectives and should be a pre¬ 
requisite for managing any systems engineering project. 

Customizable and personalized dashboards are another key feature that would 
prove very valuable. CSEs seem to spend much of their time gathering and combining 
data in order to understand the current status of various efforts and then spend additional 
time forming that status into reports for their management and stakeholders. As with 
tasking, the data gathering stage usually consists of individual and team meetings and e- 
mails which have the drawbacks of being time-consuming, non-real-time, and poorly 
documented. A dashboard on the other hand provides a more formal and real-time 
mechanism to gather status on key focus areas and metrics and create reports quickly. 
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Dashboards also allow easy communication with the project manager and higher-level 
management. 

Finally, workspaces are a key collaboration tool that would provide extreme 
benefit to the CSE, the systems engineering team, and other stakeholders. The key 
objective of workspaces is to facilitate communication and teamwork among team- 
members, managers, and stakeholders in a way that makes it both fast and easy while 
creating a formal record that can be referenced in the future. It provides a medium to li nk 
multiple conversations, actions, and tasks that would normally take place through email, 
ad-hoc discussions, and team meetings and may not be easily connected otherwise. 

E. SUMMARY 

This chapter provides a survey of four different categories of software tools that 
could support systems engineering management. Each category is described and the 
benefits and challenges are discussed. The first category is MBSE. It is a highly process 
focused technique that parallels the systems engineering processes. INCOSE predicts that 
MBSE will be fully mature and ready for full adoption at the organizational level by 2020 
and there are DOD efforts underway to embrace MBSE. The second category is PEM. It 
is a holistic approach for managing systems engineering efforts through the entire life 
cycle. The DOD is looking at PEM as a solution to help deal with significant complexity 
and to reduce costs. 

The third category is SEE. An SEE is an integrated environment for executing 
systems engineering efforts throughout the life cycle. The use of a SEE seems very 
promising but unfortunately does not seem to have been able to gain a meaningful 
foothold within DOD. The final category is Project Management tools. It contains a 
range of tools that, although do not directly relate to systems engineering, have a number 
of features that would prove useful to any team and manager. 

All four categories of tools offer features of significant benefit to a CSE. Some of 
these tools can also be used in combination to extend those benefits (such as MBSE and 
PEM). And the SEE concept presents a promising approach to having a central system 
through which the CSE can manage the systems engineering effort. However, there 
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currently does not seem to be a eonsolidated eommereially available tool or system that 
allows for seamless management of systems engineering projeets aeross all of the proeess 
areas. 
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IV. TOOL FEATURES 


As discussed in Chapter I, a systems engineering management tool is eritieal for 
sueeessful systems engineering management. Although there are multiple tools available, 
as shown in Chapter III, no eurrent eommereially available produet addresses all of the 
systems engineering proeesses in a eonsolidated and eomplete manner. In SDEA, 
Montgomery, Carlson, and Quartueeio (2012, 13) note that “The ehallenge is to provide 
the DOD engineering eommunity an “engineering system” based upon many of these 
existing tools, eoupled with tailored tools whieh will provide a more integrated 
repeatable, quantifiable proeess rather than eontinuing with the disjointed tool sets and 
ad-hoe proeesses.” The “engineering system” does not need to be a single produet 
(although it ean be), but if not, it does need to be able to eombine the use of multiple 
tools into a single system. 

One approaeh to aeeomplish this, as diseussed in Chapter III when reviewing 
SEE, is to build a eentral tool that guides the CSE through the systems engineering 
proeesses and is eapable of exehanging information with existing tools. This approaeh is 
in line with what NDIA notes as one of the top systems engineering issues in a 2010 
report, whieh is the need to “Develop a reeommended template for presenting key 
systems engineering information, ineluding aetivities, value/expeeted results, risk of not 
performing the aetivities, and future eonsequenees” (NDIA 2010, 7). The tool would aet 
as the master platform for developing, gathering, and presenting key systems engineering 
information. This ehapter deseribes the high-level requirements for sueh a tool. 

The requirements development approaeh proposed is to start with the systems 
engineering proeesses. Sinee these engineering proeesses form the pillars of systems 
engineering they make a logie starting point for any tool that is intended to guide the 
systems engineering effort. Eurthermore, sinee the system engineering proeesses apply to 
any systems engineering effort they would allow the maximum flexibility to support a 
broad range of projeets. Tailoring would allow the tool to better fit the uniqueness of eaeh 
projeet. Sueh a tool, with the eapability to tailor to eaeh projeet, eould prove espeeially 
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valuable to DOD acquisition projects that vary significantly but all require a very 
rigorous adherence to processes per the DOD Acquisition Framework (DODAF). 

A. APPROACH 

As discussed in Chapter II, systems engineering consistency and completeness 
rely heavily on standardization provided by processes. Therefore, it seems the natural 
starting point for a set of tool requirements should be these processes. In Chapter II, two 
sets of systems engineering processes were explored, DAU and INCOSE. Since the DAU 
processes are undergoing a major revision at the time of this writing, the below 
requirements set uses INCOSE processes as the starting point. The sets of processes are 
close enough, as indicated by the processes mappings presented in Chapter II, that 
differences in the resulting requirements should not be overly significant. The additional 
benefit of using INCOSE processes is that the INCOSE Systems Engineering Handbook 
clearly decomposes each process into activities and sub-activities. This makes it easier to 
trace to more detailed requirements. 

Several stipulations are in order. Eirst, the management tool is intended to be a 
guide for the CSE and not a replacement for activities and decisions that must still be 
made by humans. Therefore, not every aspect of every activity or sub-activity can be 
supported by a requirement. In some instances the tool will only be able to provide a 
minor contribution in supporting a particular activity or sub-activity. Next, the set of 
requirements here is not an exhaustive set but is intended as a starting point. Einally, it is 
important to acknowledge that the challenge of tool integration is a significant one and 
will not be addressed here beyond stating the need for such integration. As discussed in 
Chapter III the AP-233 standard does help address this challenge 

B. REQUIREMENTS 

Below is the high-level decomposition for the management tool (Eigure 13). It 
will help provide the structure for the requirements set. The processes are directly 
extracted from the INCOSE System Engineering Handbook (INCOSE 2011) and 
rearranged. 
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Figure 13. Decomposition 


The requirements are listed in the Appendix, starting with top-level requirements, 
then technical process requirements, and finally project process requirements. For 
technical process and project process requirements the process activity and next level of 
detail (here termed sub-activity) from which each requirement is derived are shown. 
These activities and sub-activities are extracted from the INCOSE Systems Engineering 
Handbook (INCOSE 2011, Ch 4-5) and reproduced here by permission from INCOSE. 
The process activities and sub-activities are being treated as the user needs and 
requirements are traced from these needs. The requirements are developed based on the 
author’s experience as well as insight gained through performing research for Chapters II 
and III. Some requirements are inspired by the capabilities of existing tools outlined in 
Chapter II as well as tools the author is familiar with. The remainder of this section will 
highlight the key features of the set of requirements provided in the Appendix: 

• templates 

• full traceability 
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• auto-generated aids 

• doeumentation of results/data 

• data review/analysis 

• link key intemal/extemal documents 

• historical database access 

• maintain history 

• build and execute scenarios/simulations 

• auditing 

• access controls. 

The following discussion takes a deeper look into each key feature. 

1. Templates 

Templates are one of the most significant features of the envisioned management 
tool. Templates would guide the systems engineering team in performing common 
analysis or developing documents. The templates would be based on best practices and 
lessons learned and would allow for tailoring. One example of a requirement in 
this category is Requirement 32: The tool shall provide customizable stakeholder 
identification template. The template could include predefined attributes such as 
stakeholder, stakeholder category, their priority, their need, the source of their need, and 
their desirable and undesirable outcomes. Another example is Requirement 125: The tool 
shall have a template for building a verification plan. Here the outline of the document 
would be provided as a starting point, with required section titles, a description of the 
information expected, and all header and footer data. Such templates allow the team to 
work from proven and endorsed starting point thereby increasing the chance of success. 
They can also allow the organization to regularly push updates to all users instead of 
working from a user pull model that may grow out of sync with multiple versions. 

2. Full Traceability 

Full traceability is another key feature that is critical for successful systems 

engineering. The goal is to ensure that there is clear traceability from stakeholders’ needs 

to requirements to the design and to verification and validation. Having multiple 
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disjointed tools that independently traek these elements or failing to formally capture this 
traceability altogether can result in gaps that lead to an end product that does not meet the 
stakeholders’ needs. An example of a requirement in this category is Requirement 76: 
The tool shall provide traceability between requirements, functions, and system elements. 
This will help ensure that the design reflects the requirements and the design description 
is formally captured for future review. 

3. Auto-generated Aids 

Auto-generated aids are a broad category that would include checklists, forms, 
task lists, punch lists, reports, and schedule snapshots among others. Pre-loaded templates 
would be populated with existing information in the tool to support various systems 
engineering tasks. An example of a requirement in this category is Requirement 276: The 
tool shall be capable of auto-generating the entrance and exit criteria checklist. The 
relevant criteria can be quickly extracted from the source document, placed into a 
checklist format, and provided to the decision maker for the particular event. 

4. Documentation of Results/Data 

The tool would be capable of recording all relevant information collected during 
testing, operation, maintenance, and disposal. Documenting this information is critical in 
identifying trends and supporting good decision making. An example of a requirement in 
the category is Requirement 200: The tool shall support logging of preventative 
maintenance actions taken. Having a single consolidated location to log this information 
would ensure that future preventative maintenance stays on schedule and there is 
sufficient history on each item. 

5. Data Review/Analysis 

Data review and analysis serves to aid in processing of data entered into the tool. 
Data review would be most useful in the development stage by cross-checking design 
data against guides, best practices, and lessons learned. An example of a requirement in 
this category is Requirement 40: The tool shall have an automated review feature that 
identifies poor and inconsistent requirements based on keywords and historical data. The 
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tool would scan all requirements and flag requirements that utilize eertain keywords or 
have a particular structure known to be an indieator for bad requirements, similar to a 
grammar cheek in word proeessing software. Another example of a requirement in this 
eategory is Requirement 179: The tool shall support eomparison of operational 
performanee data against design data and highlight areas of eoneem. The tool would 
allow for input of operational data and then would regularly eompare that data against the 
design and provide notifleations or trends as well as highlight areas where thresholds 
have been triggered. 

6. Link Key Internal/External Documents 

Systems engineering efforts usually draw on multiple doeuments outside of the 
immediate projeet. These ean inelude standards, regulations, and guides that are both 
internal and external to the organization. Linking to these guides within the tool helps 
minimize the effort of eonstantly searching for the eorrect doeument each time it is 
needed. An example of a requirement in the category is Requirement 46: The tool shall 
have the eapability to link to government and industry standards databases. Therefore, if 
a requirement referenees a government standard a hyperlink ean be ineluded to take the 
user to that speeiflc referenee, or to a loeally stored eopy of the doeument with the 
speeifie seetions of relevanee highlighted and with projeet speeifle eomment saved. 

7. Historical Database Access 

A key way to inerease efflcieney is to reuse similar produets that have proven to 
be sueeessful. A historieal database would allow for a projeet to obtain insight into 
similar efforts within the organization to understand how various proeesses were 
exeeuted and how produets were developed and to re-use elements as applieable. An 
example of a requirement in the eategory is Requirement 41: The tool shall have aceess 
to a database of historical requirements for similar systems. This would provide a starting 
point for requirements as well as history on whieh were sueeessful and whieh had issues. 
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Maintain History 


Maintaining history is a key feature that would allow for retrieval of any portion 
of a phase, proeess, or product within the project. It would also include elements such as 
configuration control of products under baseline and change history. An example of a 
requirement in the category is Requirement 92: The tool shall support storage of 
architectural design decision artifacts. All contributing artifacts such as email exchanges, 
meeting minutes, trade studies, and analysis of alternatives would be linked to the 
specific configuration item and requirement so that the history of how a design decision 
was made and supporting description could be retraced. This would minimize the risk of 
rehashing design decisions after the fact as a result of faulty recollection or change-over 
of personnel. 


9. Build and Execute Scenarios/Simulations 

Building scenarios and simulations allows systems engineers to better understand 
the results of design decisions and obtain higher certainty that the final design will meet 
stakeholder needs. Having this capability imbedded within the tool would inform key 
decisions and provide supporting evidence for future reviews and audits. An example of a 
requirement in the category is Requirement 87: The tool shall provide the capability to 
compare multiple models against pre-defined selection criteria. Multiple scenarios can be 
built and compared against each other and the selection criteria. An objective decision 
can then be made and supporting artifacts are available to show how that decision was 
reached. 


10. Auditing 

A key component of ensuring that that products are correct and processes are 
being adhered to is regular auditing. The tool will be able to trigger random and pre-set 
audits which can include both automatic and manual checks. An example of a 
requirement in the category is Requirement 307: The tool shall be capable of auto¬ 
generating an audit checklist to evaluate the Risk Management Process. A checklist 
would be generated based on the guidelines set by the organizational risk management 

process, and can be tailored to the project. Some of the answers can be auto-generated 
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based on existing artifacts and others may require manual review. The results would 
identify areas of potential improvement and metrics can be saved and kept for the life of 
the project. 

11. Access Control 

Having access control is critical to ensuring data integrity. Once baselines are 
established there needs to be assurance that data will not be manipulated without 
following an established process. An example of a requirement in the category is 
Requirement 315: The tool shall be capable of implementing access controls for all CM 
documentation. All documentation that has formally entered CM control must be 
restricted so that only authorized personal can make modifications. 

C. BENEFITS 

The envisioned systems engineering management tool would leverage all of the 
benefits of the tools described in Chapter III by being able either to integrate with those 
tools or to reproduce the functionality supported by those tools. There are three areas 
where the described systems engineering management tool would be especially 
beneficial. 

The first benefit comes from providing a standardized approach to managing a 
systems engineering effort by guiding it from start to finish. This will help normalize for 
experience level of the CSE and will be especially helpful in developing less 
experiencing CSEs. In SDEA Montgomery argues that having an integrated engineering 
system is especially pertinent now since “the workforce experience level will be 
contracting over the next decade as the baby boomers retire and the younger engineers 
grow into that role” (Montgomery, Carlson, and Quartuccio 2012, 25). This will also help 
mitigate the problem of being highly dependent on one or a few members of the team 
(CSE being the most critical) that has the entire vision in their head by forcing that vision 
to be captured in the tool. 

The second benefit is the improved insight for the CSE, management, and 
decision makers. This is enabled by being able to capture real-time status of the project at 
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any time which provides a good summary of progress and challenges. Having good 
information quickly supports better decisions and allows for identifying and mitigating 
problem areas. 

The third benefit is the ability to support organizational knowledge transfer. The 
entire project can be captured from beginning to end and then be “re-played” for post- 
analysis and for teaching purposes. This also supports easier capturing of lessons learned 
and best practices. There is less dependence on proactive team members sharing 
information with the organization and more accurate records of successes and failures 
along the way. 

D. SUMMARY 

This chapter builds a set of requirements for a central tool that supports systems 
engineering management. The approach used is to start with the INCOSE systems 
engineering processes as the central guide for building such a tool. This approach 
supports a broad range of systems engineering efforts by allowing for significant 
tailoring. The requirements are derived from the activities and sub-activities described for 
each processes. Several key stipulations are offered. First, the management tool is 
intended to be a guide for the CSE and not a replacement for activities and decisions that 
must still be made by humans. Second, the set of requirements is not an exhaustive set 
but is intended as a starting point. Final, the challenge of tool integration is recognized 
but not addressed by these requirements. 

The envisioned systems engineering management tool would leverage the benefits 
of the existing tools described in Chapter III by either integrating with them or offering 
similar functionality. There are three areas where the tool would be especially beneficial. 
The first is to provide a standardized approach to managing a systems engineering effort 
by guiding it from start to finish. This would help normalize for experience level of the 
CSE and would also reduce dependence on one or a few key individuals. The second 
benefit is added insight into progress and challenges for the CSE, management, and 
decision makers by captured real-time status of the project. The third benefit is more 
complete and reliable organizational knowledge transfer. 
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V. CONCLUSION 


A. SUMMARY 

The objectives of this thesis are to explore the key components of systems 
engineering management, conduct a survey of existing software tools that can be used to 
support systems engineering management, and propose requirements for a tool that would 
facilitate systems engineering management. The following three research questions are 
addressed. 

1. What are the key components of systems engineering management? 

In order to address this question the definition of systems engineering is 
examined. It is shown that systems engineering is an interdisciplinary, holistic approach 
that requires a systematic and process-heavy implementation for success. Then a survey 
of the systems engineering processes is performed, relying on INCOSE and DAU 
processes. By looking at the processes we understand the breadths of responsibility of the 
CSE and how important it is for the CSE to have a strong grasp of each process at all 
times. Einally, various software tools that a CSE commonly utilizes as part of the CSE 
toolbox are examined. It is noted that these tools provide a powerful mix of functionality 
but lack integration. 

2. What software tools are available that could support systems 
engineering management? 

In order to address this question a survey of the different types of software tools 
that could support systems engineering management is conducted. Eour categories of 
tools are determined to be most relevant and explored in detail. These include MBSE, 
PEM, SEE, and Project Management. Eor each category the benefits and challenges are 
listed from the perspective of supporting systems engineering management. It is 
determined that although each category provides powerful functionality that can go a 
long way towards supporting systems engineering management, there is no current 
commercially available product that addresses all of the systems engineering processes in 
a consolidated and complete manner. 
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3. What requirements would an ideal systems engineering management 
tool have? 

In order to help fill the gap identified through the seeond researeh question a set 
of requirements for an ideal systems engineering management tool are proposed. The 
starting point is the INCOSE proeesses and requirements are derived from the aetivities 
and sub-activities traced to each process. This approach leverages the benefits of existing 
tools while also contributing additional benefits. 

B. RECOMMENDATIONS 

Systems engineering is clearly a complex discipline. There is no single 
consolidated tool or a suite of integrated tools to support the entire systems engineering 
management effort. Developing such a tool will significantly benefit the systems 
engineering community. This will also significantly benefit the DOD in executing highly 
complex systems engineering efforts. However, it seems that the DOD has not yet started 
adopting SEE types of tool sets. It will be advantageous for the DOD to put a focus on 
moving in this direction. This could motivate industry to spend more resources on 
producing a product that could act as the glue for guiding a systems engineering effort. 
The starting point for such a product is recommended to be the INCOSE or DAU 
processes, as described in Chapter IV. 

C. FUTURE WORK 

The requirements developed in this thesis are just a start. There is significant 
room to further expand and improve upon these requirements. It will also be beneficial 
to survey practicing CSEs to obtain feedback on useful requirements. The next step 
would be to create a prototype systems engineering management tool that can be tested 
on a real project. 
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APPENDIX. REQUIREMENTS 


A. TOP-LEVEL REQUIREMENTS 

The requirements listed in Table 5 represent the top-level requirements for the tool. They 
apply to both projeet and teehnical proeesses. The eolumn labeled “Level” is based on the 
decomposition in figure 13, and in this case shows that these requirements are all at the 
top level. The column labeled “R#” indicates the requirement number for each 
corresponding requirement. The requirements are shown in the last column and are 
developed by the author. 


Table 5. Top-Level Requirements 


Level 1 

R# 

Requirement 

1 

1 

The tool shall provide modules focused on each of the technical 
processes identified in the INCOSE Systems Engineering Handbook 


2 

The tool shall provide modules focused on each of the project processes 
identified in the INCOSE Systems Engineering Handbook 


3 

The tool shall allow for tailoring of processes and the capability to add 
comments to describe the tailoring 


4 

The tool shall have selectable pre-defined life-cycle models that when 
selected create interdependencies between the processes 


5 

The tool shall generate a checklist showing the processes, activities, and 
sub-activities that require further attention during any particular phase 
based on the selected life-cycle model 


6 

The tool shall provide process definition hyperlinks to DAU, INCOSE, and 
other reputable systems engineering websites 


7 

The tool shall provide the capability to link to external documents 
hosted online 


8 

The tool shall auto-generate review charts based on customizable 
parameters 


9 

The tool shall auto-generate customizable dashboard views to provide 
status snapshots 


10 

The tool shall provide the capability to build and manage Plan of Action 
and Milestones (POA&Ms) or action item lists for any particular tasking 


11 

The tool shall allow for tracking of detailed entrance and exit criteria for 
any milestone, tollgate, or task 


12 

The tool shall provide customizable templates that can be based on 

DIDs or other standard formats 


13 

The tool shall be capable of requesting random audits for project 
processes per user customizable parameters 
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B. TECHNICAL PROCESS REQUIREMENTS 


The requirements in Table 6 are derived from the INCOSE teehnieal proeesses. Shaded column s include text from (INCOSE 2011) 
reproduced here by permission of the copyright holder. Columns that are not shaded are the author’s work. Each column labeled 
“Eevel” is based on the decomposition in figure 13 and identifies the level for each Process, Activity, and Requirement, as 
appropriate. The column labeled “R#” indicates the requirement number for each corresponding requirement. The requirements are 
shown in the last column and are derived by the author from each INCOSE Process, Activity, and Sub-activity. 


Table 6. Technical Process Requirements (after INCOSE 2011); 
shaded columns include text reproduced here by permission of the copyright holder. 


Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 

1.1.1 

Stakeholder 
Requirements 
Definition 
(INCOSE 2011, 

56) 

1.1.1.1 

"Elicit 

Stakeholder 
Requirements" 
(INCOSE 2011, 

59) 

l.l.l.l.l 

"Identify 

stakeholders..." 

(INCOSE 2011, 59) 

32 

The tool shall provide customizable 
stakeholder identification template 





1.1.1.1.2 

"Elicit requirements..." 
(INCOSE 2011, 59) 

33 

The tool shall support virtual working 
groups 







34 

The tool shall allow for creation of 

external stakeholder accounts 



1.1.1.2 

"Define 

Stakeholder 
Requirements" 
(INCOSE 2011, 

59) 

1.1.1.2.1 

"Define constraints 
imposed by 
agreements or 
interfaces with 
legacy...systems" 
(INCOSE 2011, 59) 

35 

The tool shall have customizable 
templates to list constraints imposed 
by agreements or legacy interfaces 





1.1.1.2.2 

"Build scenarios..." 
(INCOSE 2011, 59) 

36 

The tool shall provide scenario 
builder capability 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







37 

The tool shall support building of 
DODAF and MoDAF views 





1.1.1.2.3 

"Establish critical and 
desired system 
performance..." 

(INCOSE 2011, 60) 

38 

The tool shall allow for identifying 
thresholds and objectives and linking 
those to requirements 





1.1.1.2.4 

"Establish MOEs and 
suitability..." (INCOSE 
2011, 60) 

39 

The tool shall allow for identifying 
Measures of Effectiveness and 
Measures of Suitability and linking 
those to requirements 



1.1.1.3 

"Analyze and 
Maintain 

Stakeholder 
Requirements" 
(INCOSE 2011, 

60) 

1.1.1.3.1 

"Analyze requirements 
for clarity, 
completeness, and 
consistency" (INCOSE 
2011, 60) 

40 

The tool shall have an automated 
review feature that identifies poor 
and inconsistent requirements based 
on keywords and historical data 







41 

The tool shall have access to a 
database of historical requirements 
for similar systems 





1.1.1.3.2 

"Negotiate 

modifications..." 

(INCOSE 2011, 60) 

42 

The tool shall support recording of 
notes and attachment of files to a 
requirement or set of requirements 







43 

The tool shall have a change log to 
maintain the history of changes for 
each requirement 





1.1.1.3.3 

"Validate, record, and 
maintain stakeholder 
requirements 
throughout the system 

44 

The tool shall be able to record and 
maintain multiple levels or 
requirements 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






life cycle and 
beyond..." (INCOSE 

2011, 60) 







1.1.1.3.4 

"Establish and 
maintain a traceability 
matrix..." (INCOSE 

2011, 60) 

45 

The tool shall allow for traceability 
amongst requirements 

1.1.2 

Requirements 
Analysis 
(INCOSE 2011, 

71) 

1.1.2.1 

"Define the 

System 

Requirements" 
(INCOSE 2011, 

71) 

1.1.2.1.1 

"Selected standards - 
Identify standards 
required to meet 
quality or design 
considerations..." 
(INCOSE 2011, 75) 

46 

The tool shall have the capability to 
link to government and industry 
standards databases 







47 

The tool shall provide the capability 
to import/download relevant 
standards 







48 

The tool shall allow for comments 

and notes on common file formats 







49 

The tool shall allow for creation of 
hyperlinks between requirements 
and referenced standards 





1.1.2.1.2 

"System boundaries- 
Clearly identify system 
elements under design 
control of the project 
team and/or 
organization and 
expected interactions 

50 

The tool shall have a customizable 
system boundaries template 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






with systems external 
to that control 
boundary..." (INCOSE 
2011, 75) 









51 

The tool shall support traceability 
between system boundaries and 
Interface Control Documents (ICD) 





1.1.2.1.3 

"External interfaces - 
Functional and design 
interfaces..." (INCOSE 
2011, 75) 

52 

The tool shall have a customizable 
external interfaces template 







53 

The tool shall support traceability 
between external interfaces and ICDs 





1.1.2.1.4 

"System Functions - 
Define system 
functions that the 
system is to perform" 
(INCOSE 2011, 75) 

54 

The tool shall provide the capability 
to develop a functional 
decomposition 







55 

The tool shall provide the capability 
to develop Functional Flow Block 
Diagram (FFBD), N2 diagrams, and 
similar 





1.1.2.1.5 

"Identify all 
environmental 
factors..." (INCOSE 

2011, 75) 

56 

The tool shall provide a database of 
common environmental factors that 
may affect performance, impact 
human comfort or safety, or cause 
human error for similar systems 







57 

The tool shall have a customizable 
environmental factors template 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.1.2.1.6 

"Life-cycle process 
requirements..." 

(INCOSE 2011, 76) 

58 

The tool shall have customizable 
maintenance and disposal 
requirements templates 





1.1.2.1.7 

"Design 

considerations..." 
(INCOSE 2011, 76) 

59 

The tool shall provide databases of 
common Human Systems Integration 
(HSI), security, and environmental 
impact design considerations for 
similar systems 







60 

The tool shall have customizable HSI, 
security, and environmental impact 
templates 





1.1.2.1.8 

"Design constraints..." 
(INCOSE 2011, 76) 

61 

The tool shall provide databases of 
common design constraints including 
physical limitations, manpower, 
personnel, and other resource 
constraints on system operations for 
similar systems 







62 

The tool shall have customizable 
templates for physical limitations, 
manpower, personnel, and other 
resource constraints on system 
operations 







63 

The tool shall have customizable 
templates for external interface 
constraints 



1.1.2.2 

"Analyze and 
Maintain the 
System 

Requirements" 

1.1.2.2.1 

"Design verification 
criteria..." (INCOSE 

2011, 76) 

64 

The tool shall allow for definition of 
requirement verification approach 
and criteria in parallel with 
requirement development 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 




(INCOSE 2011, 

76) 









1.1.2.2.2 

"Maintain continuity 
of configuration 
control and 
traceability" (INCOSE 
2011, 76) 

65 

The tool shall maintain a history of all 
requirement changes, including 
changes to any requirement 
attributes 







66 

The tool shall allow for binning of 
requirements into customizable bins 







67 

The tool shall maintain requirements 
traceability 







68 

The tool shall allow for baselining of 
requirements beyond which changes 
require specific user permissions 







69 

The tool shall support user accounts 
with customizable permissions, 
including a permission that toggles 
the ability to make requirements 
changes after a baseline 

1.1.3 

Architectural 
Design (INCOSE 
2011, 96) 

1.1.3.1 

"Define the 

Architecture" 
(INCOSE 2011, 

98) 

1.1.3.1.1 

"Define a consistent 
logical architecture..." 
(INCOSE 2011, 98) 

70 

The tool shall support building 
models of the logical architecture 







71 

The tool shall provide an 
environment for building functional 
decompositions 







72 

The tool shall support definition of 
attributes and interactions amongst 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 








functions 





1.1.3.1.2 

"Partition system 
requirements and 
allocate them to 
system elements with 
associated 
performance 
requirements..." 

(INCOSE 2011, 98) 

73 

The tool shall support building 
models of the physical architecture 







74 

The tool shall provide an 
environment for building physical 
decompositions 







75 

The tool shall support definition of 
attributes and interactions amongst 
system elements 







76 

The tool shall provide traceability 
between requirements, functions, 
and system elements 







77 

The tool shall support linking and 
analyzing of existing solutions 
associated with each system element 





1.1.3.1.3 

"Identify interfaces 
and interactions 
between system 
elements...and with 
external and enabling 
systems" (INCOSE 

2011, 98) 

78 

The tool shall support documenting 
and building models of interfaces 
and interactions amongst system 
elements 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







79 

The tool shall support documenting 
and building models of interfaces 
and interactions between system 
elements and external and enabling 
systems 





1.1.3.1.4 

"Define V&V criteria..." 
(INCOSE 2011, 99) 

80 

The tool shall support traceability 
from requirements verification 
approach and criteria down to the 
system elements 







81 

The tool shall support building 
models of system element 
verification 







82 

The tool shall provide a database of 
common verification criteria for 
similar systems 



1.1.3.2 

"Analyze and 
Evaluate the 

Architecture" 
(INCOSE 2011, 

99) 

1.1.3.2.1 

"Evaluate COTS 

elements for 
compatibility with the 
design" (INCOSE 2011, 
99) 

83 

The tool shall support storing and 
linking of manufacturer spec sheets 







84 

The tool shall provide the capability 
to display requirements by function 
and system element 







85 

The tool shall provide the capability 
to customize physical elements 
within the model based on COTS 
specs and run a model to determine 
compatibility and performance 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.1.3.2.2 

"Evaluate alternative 
design solutions..." 
(INCOSE 2011, 99) 

86 

The tool shall provide the capability 
to develop selection criteria and 
trace it from the source 
requirements 







87 

The tool shall provide the capability 
to compare multiple models against 
pre-defined selection criteria 







88 

The tool shall provide a template for 
creating trade studies 





1.1.3.2.3 

"Support definition of 
the system integration 
strategy and plan..." 
(INCOSE 2011, 99) 

89 

The tool shall provide a template for 
building an integration strategy 







90 

The tool shall provide the capability 
to display all system internal and 
external interfaces 



1.1.3.3 

"Document and 

Maintain the 

Architecture" 
(iNCOSE 2011, 

99) 

1.1.3.3.1 

"Document and 

maintain the 
architectural design 
and relevant decisions 

made to reach 
agreement on the 
baseline design" 

(INCOSE 2011, 99) 

91 

The tool shall maintain 
documentation, models, and any 
additional artifacts that represent 
the baseline design 







92 

The tool shall support storage of 
architectural design decision artifacts 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.1.3.3.2 

"Establish and 

maintain the 
traceability between 
requirements and 
system elements" 
(INCOSE 2011, 99) 

93 

The tool shall maintain a history of all 
design decisions 







94 

The tool shall maintain a history of all 
architectural design changes 







95 

The tool shall maintain traceability 
between the requirements and 
architectural design 







96 

The tool shall allow for baselining of 
the architecture beyond which 
changes require specific user 
permissions 







97 

The tool shall support user accounts 
with customizable permissions, 
including a permission that toggles 
the ability to make architectural 
changes after a baseline 

1.1.4 

Implementation 
(INCOSE 2011, 
115) 

1.1.4.1 

"Plan the 
Implementation" 
(INCOSE 2011, 

118) 

1.1.4.1.1 

"Develop an 
implementation 
strategy - 

define...procedures, 
tools and equipment..., 
implementation 
tolerances, and the 
means and criteria for 
auditing 

98 

The tool shall provide a template for 
building an implementation strategy 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






configuration..." 

(INCOSE 2011, 118) 









99 

The tool shall provide the capability 
to trigger and record random audits 
of the configuration against the 
design documentation 



1.1.4.2 

"Perform 
Implementation" 
(INCOSE 2011, 

118) 

1.1.4.2.1 

"Develop data for 
training users...for 
operating and 
maintaining..." 

(INCOSE 2011, 118) 

100 

The tool shall support documenting 
training and safety information for 
each system element 







101 

The tool shall provide traceability 
between system elements and 
related training and safety 
documentation 





1.1.4.2.2 

"Complete detailed 
product, process, 
material 

specifications...and 
corresponding analysis 
and produce 
documented evidence 
of implementation 
compliance [including] 
conduct[ing] peer 
reviews and 

102 

The tool shall provide a template for 
building specifications documents 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






testing...[and] 
conducting hardware 
conformation audits..." 
(INCOSE 2011, 118) 









103 

The tool shall provide traceability 
between each model and the 
specifications documents 







104 

The tool shall auto-generate 
implementation compliance 
checklists from requirements, 
models, and specifications 





1.1.4.2.3 

"Prepare initial 
training capability and 
draft training 
documentation..." 
(INCOSE 2011, 118) 

105 

The tool shall provide a template for 
preparing training documentation, 
with segmentation between 
operations and maintenance 







106 

The tool shall provide traceability 
between system elements and 
training documentation 





1.1.4.2.4 

"Prepare hazardous 
materials log, if 
applicable" (INCOSE 
2011, 118) 

107 

The tool shall provide a template for 
preparing hazardous materials logs 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







108 

The tool shall provide the capability 
to link between system elements and 
their hazardous materials log entries. 





1.1.4.2.5 

"Train initial operators 
and maintainers..." 
(INCOSE 2011, 119) 

109 

The tool shall provide a template for 
a training strategy 







110 

The tool shall auto-generate trainer 
and maintainer checklists from 
training documentation 







111 

The tool shall maintain a list of 
trained operators and maintainers 

1.1.5 

Integration 
(INCOSE 2011, 
120) 

1.1.5.1 

"Plan 

Integration" 
(INCOSE 2011, 

122) 

1.1.5.1.1 

"Define the integration 
strategy" (INCOSE 

2011, 122) 

112 

The tool shall provide a template for 
building an integration plan 







113 

The tool shall allow for segmentation 
of integration into phases that can 
have different objectives and can be 
linked as needed 





1.1.5.1.2 

"Schedule integration 
testing tools and 
facilities" (INCOSE 

2011, 122) 

114 

The tool shall provide the capability 
to record and track key testing tools 
and facilities details, including 
scheduling 



1.1.5.2 

"Perform 
Integration" 
(INCOSE 2011, 

122) 

1.1.5.2.1 

"Assemble system 
elements according to 
the integration plan" 
(INCOSE 2011, 122) 

115 

The tool shall allow regular progress 
updates by the integration team to 
track detailed integration status 







116 

The tool shall auto-generate 
proposed tasking lists based on the 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 








integration plan and progress 
updates 







117 

The tool shall generate a 
visualization of the integration 
progress by annotating system 
logical and physical architecture 
models 





1.1.5.2.2 

"Validate and verify 
interfaces..." (INCOSE 
2011, 122) 

118 

The tool shall auto-generate an 
interfaces checklist with relevant 

characteristics from the 
requirements and design documents 







119 

The tool shall provide an anomaly 
tracker 







120 

The tool shall have the capability to 
elevate anomalies and deficiencies 
and track them through a POA&M 





1.1.5.2.3 

"Verify and analyze 
assemblies..." (INCOSE 
2011, 122) 

121 

The tool shall auto-generate a 
checklist of functions from the 
requirements and design documents 





1.1.5.2.4 

"Document integration 
testing and analysis 
results" (INCOSE 2011, 
122) 

122 

The tool shall provide templates for 
documenting integration testing and 
analysis results 





1.1.5.2.5 

"Document and 

control the 

architectural 
baseline..." (INCOSE 
2011, 122) 

123 

The tool shall provide the capability 
to capture and store architectural 
baselines 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







124 

The tool shall provide the capability 
to execute a formal change process 
for any architectural baseline 
modifications 

1.1.6 

Verification 
(INCOSE 2011, 
126) 

1.1.6.1 

"Plan 

Verification" 
(INCOSE 2011, 

128) 

1.1.6.1.1 

"Schedule, confirm, 
and install verification 
enabling systems" 
(INCOSE 2011, 128) 

125 

The tool shall provide a template for 
building a verification plan 







126 

The tool shall provide the capability 
to record and track details related to 
verification enabling systems, 
including scheduling and VV&A 







127 

The tool shall provide the capability 
to annotate the logical and physical 
architecture models to show the 
verification architecture, including 
explicitly identifying verification 
enabling systems 







128 

The tool shall provide the capability 
to document differences between 

the test environment and 
operational environment, including 
capturing a risk assessment of the 
difference 







129 

The tool shall provide the capability 
to develop high-level verification 
concepts linked to requirements 



1.1.6.2 

"Perform 

Verification" 

1.1.6.2.1 

"Develop verification 
procedures" (INCOSE 

130 

The tool shall provide a template for 
building verification procedures 
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Level 3 


Process (after 
INCOSE 2011) 


Level 4 


Activity (after 
INCOSE 2011) 

(INCOSE 2011, 
128) 


Level 5 


1.1.6.2.2 


1.1.6.2.3 



Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 


2011, 128) 





131 

The tool shall allow for development 
of a verification test step library, 
including linking to external test step 
databases 



132 

The tool shall auto-generate 
verification witness sign-off forms 
based on configurable parameters 


"Conduct verification 

activities...to 

demonstrate 
compliance with 
requirements" 

(INCOSE 2011, 128) 

133 

The tool shall be capable of 
generating day by day schedule 
snapshots of the verification 
schedule 



134 

The tool shall be capable of capturing 
daily progress updates and 
calculating whether the verification 
activity is on track 


"Document 

verification results and 

enter data into the 
RVTM" (INCOSE 2011, 
128) 

135 

The tool shall provide the capability 
to document verification results, 
including saving red-lined test 
procedures 



136 

The tool shall provide a template for 
building a verification report 



137 

The tool shall link verification results 
with the requirements database 



138 

The tool shall auto-generate an 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 








RVTM 

1.1.7 

Transition 
(INCOSE 2011, 
131) 

1.1.7.1 

"Plan the 

Transition" 
(INCOSE 2011, 

134) 

1.1.7.1.1 

"Prepare a transition 
strategy, including 
operator training, 
logistics support, 
delivery strategy, and 
problem 

rectification/resolution 
strategy" (INCOSE 

2011, 134) 

139 

The tool shall provide a template for 
building a training plan 







140 

The tool shall provide a template for 
building an ILS plan (i.e. Life Cycle 
Support Plan, Integrated Support 

Plan, etc.) 







141 

The tool shall support delivery 
planning including documenting 
shipping lead times, action item 
tracking, and need dates 





1.1.7.1.2 

"Develop installations 
procedures" (INCOSE 
2011, 134) 

142 

The tool shall provide a template for 
building an installation plan 







143 

The tool shall provide a template for 
building the installation procedures 







144 

The tool shall allow linking of 
installation drawings to installation 
procedures 



1.1.7.2 

"Perform the 

Transition" 
(INCOSE 2011, 

1.1.7.2.1 

"Prepare the 
installation site and 
install system..." 

145 

The tool shall allow for 
documentation of regular progress 
updates by the installation team to 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 




134) 


(INCOSE 2011, 134) 


track detailed installation status 







146 

The tool shall generate a 
visualization of the installation 
progress by annotating high-level 
installation drawings 





1.1.7.2.2 

"Train the users...and 

affirm users have the 
knowledge and skill 
levels necessary to 
perform Operation 
and Maintenance 
activities." (INCOSE 
2011, 134) 

147 

The tool shall support development 
of computer based training modules 







148 

The tool shall support linking each 
system element to any existing 
training materials (i.e. COTS and 
Government Off the Shelf (GOTS) 
training materials) 







149 

The tool shall support development 
of operator and maintainer 
prerequisites checklists 





1.1.7.2.3 

"Receive final 

confirmation that the 
system meets...[user's] 
needs. This process 
typically ends with a 
formal, written 

150 

The tool shall auto-generate a list of 
all applicable documents (as 
customizable by the user) that 
support successful delivery of system 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






acknowledgement..." 
(INCOSE 2011, 134) 







1.1.7.2.4 

"Post-implementation 
problems are 
documented and may 
lead to corrective 
actions or changes to 
the requirements" 
(INCOSE 2011, 134) 

151 

The tool shall provide a template for 
documenting post-implementation 
problems and linking to affected 
requirements and action items 

1.1.8 

Validation 
(INCOSE 2011, 
135) 

1.1.8.1 

"Plan Validation" 
(INCOSE 2011, 

137) 

1.1.8.1.1 

Develop a validation 
strategy (INCOSE 2011, 
137) 

152 

The tool shall provide a template for 
building a validation plan 







153 

The tool shall provide the capability 
to annotate the logical and physical 
architecture models to show the 

validation architecture 







154 

The tool shall provide the capability 
to develop and model assessment 
scenarios 



1.1.8.2 

"Perform 

Validation" 
(INCOSE 2011, 

137) 

1.1.8.2.1 

"Develop validation 
procedures..." (INCOSE 
2011, 137) 

155 

The tool shall provide a template for 
building validation procedures 







156 

The tool shall allow for development 
of a validation test step library, 
including linking to external test step 


71 





Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 








databases 







157 

The tool shall auto-generate 
validation witness sign-off forms 
based on configurable parameters 





1.1.8.2.2 

"Ensure readiness to 

conduct validation..." 
(INCOSE 2011, 137) 

158 

The tool shall allow for tracking of 
entrance criteria 







159 

The tool shall provide the capability 
to record and track details related to 
validation enabling systems, 
including scheduling and VV&A 





1.1.8.2.3 

"Support in-process 
validation throughout 
the system 

development" (INCOSE 
2011, 137) 

160 

The tool shall link user generated 
validation considerations to each of 
the following technical processes: 
requirements analysis, architectural 
design, implementation, integration, 
verification, and transition 





1.1.8.2.4 

"Conduct validation to 

demonstrate 

conformance to 

stakeholder 

requirements" 

(INCOSE 2011, 138) 

161 

The tool shall be capable of 
generating day by day schedule 
snapshots of the validation schedule 







162 

The tool shall be capable of capturing 
daily progress updates and 
calculating whether the validation 
activity is on track 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.1.8.2.4 

"If anomalies are 
detected, analyze for 
corrective actions and 

detect trends in 
failures..." (INCOSE 

2011, 138) 

163 

The tool shall provide a template for 
recording anomalies 







164 

The tool shall support generation of 
anomaly burn-down POA&Ms 







165 

The tool shall provide templates for 
troubleshooting techniques, such as 
fishbone diagrams, that can be linked 
to anomalies 







166 

The tool shall have the capability to 
plot failures over time and against 
specific configuration items or 
subsystems to support failure trend 
analysis 





1.1.8.2.5 

"Recommend 

corrective actions and 

obtain stakeholder 
acceptance of 
validation results" 
(INCOSE 2011, 138) 

167 

The tool shall support documenting 
of corrective actions for each 
anomaly 







168 

The tool shall support documenting 
of a regression test plan for each 
anomaly 





1.1.8.2.6 

"Document validation 

results and enter data 

into the RVTM" 

169 

The tool shall provide the capability 
to document validation results, 
including saving red-lined test 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 138) 


procedures 







170 

The tool shall provide a template for 
building a validation report 







171 

The tool shall link validation results 
with the requirements database 

1.1.9 

Operation 
(INCOSE 2011, 
139) 

1.1.9.1 

"Prepare for 
Operations" 
(INCOSE 2011, 

141) 



172 

The tool shall provide a template for 
building a concept of operations 







173 

The tool shall support building 
models to visualize the Concept of 
Operations and scenarios 







174 

The tool shall provide a template for 
a training package, and link to DOD 
and service specific training 
standards 



1.1.9.2 

"Perform 
Operational 
Activation and 

Check-out" 
(INCOSE 2011, 

141) 

1.1.9.2.1 

"Provide operator 
training and maintain 
qualified staff" 

(INCOSE 2011, 141) 

175 

The tool shall support development 
of an operator training plan and task 
list 







176 

The tool shall support development 
of an operator qualifications 
checklist 



1.1.9.3 

"Use System for 
Operations" 

1.1.9.3.1 

"Execute ConOps for 
the system-of- 

177 

The tool shall auto-generate 
execution templates from the 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 




(INCOSE 2011, 

141) 


interest" (INCOSE 

2011, 141) 


Concept of Operations and operator 
task list 





1.1.9.3.2 

"Track system 
performance and 
account for 
operational 
availability" (INCOSE 
2011, 141) 

178 

The tool shall perform operational 
availability calculations based on 
issue and anomaly data 





1.1.9.3.3 

"Perform operational 
analysis" (INCOSE 

2011, 141) 

179 

The tool shall support comparison of 
operational performance data 
against design data and highlight 
areas of concern 







180 

The tool shall support comparison of 
operational cost data against design 
data and highlight areas of concern 



1.1.9.4 

"Perform 

Operational 

Problem 

Resolution" 
(INCOSE 2011, 

141) 

1.1.9.4.1 

"Manage operational 
support logistics" 
(INCOSE 2011, 141) 

181 

The tool shall support documenting 
operational issues and anomalies 





1.1.9.4.2 

"Document system 
status and actions 
taken" (INCOSE 2011, 
141) 

182 

The tool shall support regular logging 
of system status and actions taken 





1.1.9.4.3 

"Report malfunctions 
and make 

recommendations for 
improvement" 

183 

The tool shall support recording of 
malfunctions and auto-generate 
recommendations based on a look¬ 
up database 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 141) 









184 

The tool shall support linking to a 
database of malfunctions and 

corrective actions 



1.1.9.5 

"Support the 
Customer" 
(INCOSE 2011, 

141) 



185 

The tool shall be capable of 
generating tailored operation status 
reports for a specific period of time 
or for the life of the system 







186 

The tool shall be capable of pushing 
regular operation status updates to 
the customer 

1.1.10 

Maintenance 
(INCOSE 2011, 
142) 

1.1.10.1 

"Plan 

Maintenance" 
(INCOSE 2011, 

144) 

1.1.10.1.1 

"Establish a 
maintenance strategy" 
(INCOSE 2011, 144) 

187 

The tool shall have a template for 
building a maintenance strategy 







188 

The tool shall support development 
of a maintainer training plan and task 
list 







189 

The tool shall support documenting 
of maintenance actions for each 
configuration item 





1.1.10.1.2 

"Define maintenance 

constraints on the 
system requirements" 
(INCOSE 2011, 144) 

190 

The tool shall allow for linking of 
maintenance constraints to system 
requirements 


76 






Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.1.10.1.3 

"Obtain the enabling 
systems, system 
elements, and other 
services used for 

maintenance of the 
system" (INCOSE 2011, 
144) 

191 

The tool shall support 
documentation and tracking of all 
maintenance agreements and 
highlight upcoming renewal dates 







192 

The tool shall support logging and 
tracking of maintenance enabling 
systems 





1.1.10.1.4 

"Monitor 

replenishment levels 
of spare parts" 

(INCOSE 2011, 144) 

193 

The tool shall track all spare parts 
and locations 







194 

The tool shall perform spare levels 
calculations to support the required 
operational availability 







195 

The tool shall maintain a list of 

vendors and estimated lead time for 
all spares 





1.1.10.1.5 

"Manage the skills and 
availability of trained 
maintenance 
personnel" (INCOSE 
2011, 145) 

196 

The tool shall support development 
of a maintainer qualifications 
checklist 







197 

The tool shall maintain a list of all 
qualified maintenance personnel 
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Level 3 


Process (after 
INCOSE 2011) 


Level 4 


Activity (after 
INCOSE 2011) 




1.1.10.2 

Perform 

Maintenance 






























Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 

1.1.10.2.1 

"Implement 
maintenance and 
problem resolution 
procedures..." (INCOSE 
2011, 145) 

198 

The tool shall support development 
of a preventative maintenance 
schedule and highlight near term and 
late tasks 



199 

The tool shall auto-generate a list of 
maintenance activities for each 
configuration item 

1.1.10.2.2 

"Maintain a history of 
failures, actions taken, 
and other trends..." 
(INCOSE 2011, 145) 

200 

The tool shall support logging of 
preventative maintenance actions 
taken 



201 

The tool shall be capable of 
generating a list of preventative 
maintenance actions taken and plot 
against time 



202 

The tool shall support logging of all 
failures 



203 

The tool shall be capable of 
generating a list of historical failures 
and plot against time 

1.1.10.2.3 

"Monitor customer 

satisfaction with 
system and 
maintenance support" 
(INCOSE 2011, 145) 

204 

The tool shall be capable of 
generating tailored support status 
reports for a specific period of time 
or for the life of the system 



205 

The tool shall be capable of pushing 
regular support status updates to the 
customer 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 

1.1.11 

Disposal 
(INCOSE 2011, 
145) 

1.1.11.1 

"Plan Disposal" 
(INCOSE 2011, 

148) 

1.1.11.1.1 

"Review the Concept 
of Disposal..." (INCOSE 
2011, 148) 

206 

The tool shall have a template for 
documenting all hazardous materials 





1.1.11.1.2 

"Define the Disposal 
Strategy" (INCOSE 

2011, 148) 

207 

The tool shall have a template for 
building a disposal strategy 







208 

The tool shall support 
documentation of required 
deactivation, disassembly, and 
removal steps for each element 





1.1.11.1.3 

"Impose associated 
constraints on the 
system requirements" 
(INCOSE 2011, 148) 

209 

The tool shall allow for linking of 
disposal constraints to system 
requirements 



1.1.11.2 

"Perform 

Disposal" 

(INCOSE 2011, 

148) 

1.1.11.2.1 

"Deactivate the 

elements to be 
terminated" (INCOSE 
2011, 148) 

210 

The tool shall auto-generate a 
checklist for deactivation of each 

element 







211 

The tool shall auto-generate 
procedures for deactivation of each 
element 





1.1.11.2.2 

"Disassemble the 

elements for ease of 
handling" (INCOSE 

2011, 148) 

212 

The tool shall auto-generate a 
checklist for disassembly of each 
element 







213 

The tool shall auto-generate 
procedures for disassembly of each 
element 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.1.11.2.3 

"Remove the elements 
and any associated 
waste products from 
the operational site" 
(INCOSE 2011, 148) 

214 

The tool shall auto-generate a 
checklist for removal of each 

element 







215 

The tool shall auto-generate 
procedures for removal of each 
element 



1.1.11.3 

"Finalize the 
Disposal" 

(INCOSE 2011, 

148) 

1.1.11.3.1 

"Maintain 

documentation of all 
Disposal activities and 
residual hazards" 
(INCOSE 2011, 148) 

216 

The tool shall support documenting 
all disposal activities taken 







217 

The tool shall support tracking of all 
hazardous material from removal to 
disposal 
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C. PROJECT PROCESS REQUIREMENTS 


The requirements in Table 7 are derived from the INCOSE projeet proeesses. Shaded eolumns inelude text from (INCOSE 2011) 
reprodueed here by permission of the eopyright holder. Columns that are not shaded are the author’s work. Eaeh eolurnn labeled 
“Eevel” is based on the deeomposition in figure 13 and identifies the level for eaeh Proeess, Aetivity, and Requirement, as 
appropriate. The column labeled “R#” indicates the requirement number for each corresponding requirement. The requirements are 
shown in the last column and are derived by the author from each INCOSE Process, Activity, and Sub-activity. 


Table 7. Project Process Requirements (after INCOSE 2011); shaded columns include text reproduced here by permission of the 

copyright holder. 


Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 

1.2.1 

Project 

Planning 
(INCOSE 2011, 
178) 

1.2.1.1 

Define the 

Project (INCOSE 
2011, 182) 

1.2.1.1.1 

"Analyze the 
project proposal 
and related 
agreements to 
define the project 
scope" (INCOSE 
2011, 182) 

218 

The tool shall link to a database of previous 
proposals 







219 

The tool shall provide a template for 
building a scope document (i.e. Statement 
of Work (SOW)) 





1.2.1.1.2 

"Identify project 
objectives and 
project 
constraints" 

(INCOSE 2011, 

182) 

220 

The tool shall provide a template for 
documenting project constraints and 
objectives 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.2.1.1.3 

"Establish tailoring 
of organization 
procedures and 
practices to carry 
out planned 
effort" (INCOSE 
2011, 182) 

221 

The tool shall link to organizational 
procedures and practices 







222 

The tool shall provide a tailoring wizard to 
tailor organizational procedures and 
practices and output the tailored 
document 





1.2.1.1.4 

"Define and 

maintain a life 
cycle mode that is 
tailored from the 
defined life cycle 
models of the 
organization" 
(INCOSE 2011, 

182) 

223 

The tool shall link to organizationally 
defined life-cycle models 







224 

The tool shall provide a tailoring wizard to 
tailor organizationally defined life-cycle 
models and output the tailored model 







225 

The tool shall support tracking of progress 
against the tailored organizational life- 
cycle model by linking to progress for each 
process 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 



1.2.1.2 

"Plan Project 
Resources" 
(INCOSE 2011, 
182) 

1.2.1.2.1 

"Establish the 

roles and 

responsibilities for 
project authority" 
(INCOSE 2011, 

182) 

226 

The tool shall provide a template for 
building the project organizational 
hierarchy 







227 

The tool shall provide a template for 
building a project management plan 







228 

The tool shall provide roles and 
responsibilities templates for each role 
defined in the project organizational 
hierarchy, including touch points between 
positions 







229 

The tool shall generate position 
descriptions from the defined roles and 
responsibilities to support hiring 





1.2.1.2.2 

"Define top-level 
work packages for 
each task and 
activity...[and tie] 
to required 
resources and 
procurement 
strategies" 

(INCOSE 2011, 

182) 

230 

The tool shall link to the required work 
package structure either per the 
organization or per the contract 







231 

The tool shall provide a template for 
populating each work package with 
detailed tasks and activities 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







232 

The tool shall provide the capability to link 
work packages to the project schedule 







233 

The tool shall provide the capability to 
identify resources (including manpower 
and cost) for each work package 





1.2.1.2.3 

"Develop a project 
schedule based on 
objectives and 
work estimates" 
(INCOSE 2011, 

182) 

234 

The tool shall provide the capability to 
build a resource loaded project schedule 







235 

The tool shall provide the capability to link 
project schedule tasks to project objectives 
(i.e., explicit SOW tasks) 





1.2.1.2.4 

"Define the 

infrastructure and 
services required" 
(INCOSE 2011, 

182) 

236 

The tool shall provide a template for 
defining the required infrastructure and 
services (i.e.. facilities, contracts support, 

IT, etc) 





1.2.1.2.5 

"Define costs and 
estimate project 
budget" (INCOSE 
2011, 182) 

237 

The tool shall provide a template for 
building a Basis of Estimate, based on the 
scope and work packages and linked to the 
project schedule 





1.2.1.2.6 

"Plan the 
acquisition of 
materials, goods 
and enabling 
systems services" 

238 

The tool shall support linking of acquisition 
of materials, goods, and enabling systems 
to the Basis of Estimate and project 
schedule 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 

182) 





1.2.1.3 

Plan Project 
Technical and 
Quality 
Management 

1.2.1.3.1 

"Prepare a 

Systems 

Engineering Plan 
(SEP); tailor the 
Quality, 

Configuration, Risk 
and Information 
Management 
plans to meet the 
needs of the 
project" (INCOSE 
2011, 182) 

239 

The tool shall provide a template for 
building a SEP 







240 

The tool shall provide templates for 
building the QA, Configuration 

Management (CM), Risk, and Information 
Management plans 







241 

The tool shall link to a database of QA, CM, 
Risk, and Information Management plans 
and provide a template for tailoring of 
those plans 





1.2.1.3.2 

"Tailor the 
organizational Risk 
Management 
Processes and 
practices in 
accordance with 

242 

The tool shall provide a tailoring wizard to 
tailor organizational risk management 
processes and output the tailored 
document 
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Level 3 


Process (after 
INCOSE 2011) 


Level 4 


Activity (after 
INCOSE 2011) 


Level 5 











1.2.1.3.3 



1.2.1.4 

"Activate the 
Project" 

(INCOSE 2011, 
183) 


1.2.2 

Project 

Assessment and 
Control (INCOSE 
2011, 197) 

1.2.2.1 

"Assess the 
Project" 

(INCOSE 2011, 
201) 

1.2.2.1.1 


Sub-activity (after 
INCOSE 2011) 

the agreements 
and the SEP..." 


R# 


(INCOSE 2011, 
182) 

"Tailor the 
organizational 
Configuration 
Management 
Processes and 
practices in 
accordance with 
the agreements 
and the SEP..." 


(INCOSE 2011, 
182) 


243 


"Determine actual 
and projected cost 
against budget, 
actual and 
projected time 
against schedule, 
and deviations in 
project quality" 
(INCOSE 2011, 

201 ) 


244 


Requirement 


The tool shall provide a tailoring wizard to 
tailor organizational configuration 
management processes and output the 
tailored document 


The tool shall link to any organizational 
tools or enterprise systems to allow for 
formal activation of the project 


The tool shall provide a template for 
developing a project controls strategy 
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245 






Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







246 

The tool shall support the capability to 
implement EVM 







247 

The tool shall be capable of comparing 
actual and projected costs against budget 
using either EVM or user configurable 
metrics 







248 

The tool shall be capable of comparing 
actual and projected progress against the 
project schedule using either EVM or user 
configurable metrics 







249 

The tool shall be capable of documenting 
user customizable quality metrics and 
comparing against plans 





1.2.2.1.2 

"Evaluate the 

effectiveness and 
efficiency of the 
performance of 
project activities" 
(INCOSE 2011, 

201) 

250 

The tool shall generate cost, schedule, and 
risk progress reports at a user defined 
frequency 







251 

The tool shall support calculation of a 
Defense Contract Management Agency 
(DCMA) 14 point schedule assessment and 
highlight weaknesses 





1.2.2.1.3 

"Evaluate the 
adequacy and the 
availability of the 
project 

infrastructure" 

252 

The tool shall support documenting of all 
project infrastructure needs and how they 
are to be (or are being) met 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 

201) 









253 

The tool shall be capable of tracking 
infrastructure needs and availability, and 
provide alerts of availability conflicts 





1.2.2.1.4 

"Evaluate project 
progress against 
established criteria 

and milestones" 
(INCOSE 2011, 

201) 

254 

The tool shall be capable of displaying cost 
and schedule progress to any user defined 
milestone 







255 

The tool shall track satisfactory completion 
of contractual items and requirements and 
be able to generate displays showing this 
progress 





1.2.2.1.5 

"Conduct required 
reviews, audits, 
and inspections to 
determine 

readiness to 
proceed to next 
milestone" 

(INCOSE 2011, 

201) 

256 

The tool shall support user configurable 
review, audit, and inspection templates 







257 

The tool shall link to review, audit, and 
inspection guidance from the organization 
and contract 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







258 

The tool shall support linking of reviews, 
audits, and inspections to milestone 
entrance and exit criteria 





1.2.2.1.6 

"Monitor critical 

tasks and new 
technologies..." 
(INCOSE 2011, 

201) 

259 

The tool shall support identification of a 
critical path 







260 

The tool shall support identification of 
critical tasks for heightened monitoring 





1.2.2.1.7 

"Make 

recommendations 
for adjustments to 
project 

plans..."(INCOSE 
2011, 201) 

261 

The tool shall auto-generate areas of 
concern based on schedule, cost, and 
performance progress 





1.2.2.1.8 

"Communicate 

status as 
designated in 
agreements, 
policies, and 
procedures" 

(INCOSE 2011, 

201) 

262 

The tool shall provide report templates 
based on organizational and contractual 
requirements 







263 

The tool shall auto-populate reports based 
on user configurable parameters and links 





1.2.2.1.9 

"Analyze 
assessment 
results" (INCOSE 

264 

The tool shall support user configurable 
displays of project controls assessment 
results 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






2011, 201) 





1.2.2.2 

"Control the 
Project" 

(INCOSE 2011, 
201) 

1.2.2.2.1 

"Initiate corrective 

actions when 

assessments 

indicate deviation 
from approved 
plans" (INCOSE 

2011, 201) 

265 

The tool shall provide a list of corrective 
action suggestions 







266 

The tool shall support user configurable 
triggers for plan deviations and provide an 
alert 





1.2.2.2.2 

"Initiate 

preventive actions 
when assessments 

indicate a trend 

toward deviation" 
(INCOSE 2011, 

201) 

267 

The tool shall provide a list of preventive 
action suggestions 







268 

The tool shall support user configurable 
triggers for deviation trends and provide 
an alert 





1.2.2.2.3 

"Initiate problem 
resolution when 

assessments 

indicate non¬ 
conformance with 
performance 
success criteria" 

269 

The tool shall provide a problem resolution 
template that includes performance 
success criteria 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 

201) 







1.2.2.2.4 

"Establish work 
items and changes 
to schedule to 

reflect actions 
taken" (INCOSE 
2011, 201) 

270 

The tool shall support development and 
tracking of a problem resolution POA&M 





1.2.2.2.5 

"Negotiate with 
suppliers for any 
goods or services 
acquired from 
outside the 
organization" 
(INCOSE 2011, 

201) 

271 

The tool shall provide a template for 
supplier agreements 







272 

The tool shall be capable of tracking all 
suppliers and supplier agreements 





1.2.2.2.6 

"Make the 

decision to 
proceed, or not to 
proceed, when 
assessments 
support a tollgate 
or milestone 
event" (INCOSE 
2011, 201) 

273 

The tool shall link to all entrance and exit 
criteria for all tollgate and milestone 
events from the organization and contract 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







274 

The tool shall support tailoring of the 
entrance and exit criteria 







275 

The tool shall support linking each 
entrance and exit criteria to specific 
documents, models, or any other data 
contained within the tool or linked to the 

tool 







276 

The tool shall be capable of auto¬ 
generating the entrance and exit criteria 
checklist 







277 

The tool shall be capable of providing 
suggestions of what artifacts are 
commonly used for a particular entrance or 
exit criteria 







278 

The tool shall be capable of providing an 
assessment whether all entrance or exit 

criteria are linked to an artifact 



1.2.2.3 

"Close the 
Project" 

(INCOSE 2011, 
201) 



279 

The tool shall link to any organizational 
tools or enterprise systems to allow for 
formal close out of the project 

1.2.3 

Decision 
Management 
(INCOSE 2011, 
202) 

1.2.3.1 

"Plan and 

Define 

Decisions" 
(INCOSE 2011, 
204) 

1.2.3.1.1 

"Identify the need 
for a decision and 
the strategy for 
making the 
decision, including 
desired outcomes 

and measureable 

success criteria" 

280 

The tool shall provide a decision analysis 
resolution template, which includes 
measureable success criteria 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 

204) 









281 

The tool shall support setting of triggers for 
commencing the decision analysis 
resolution process 



1.2.3.2 

"Analyze the 
Decision 

Information" 
(INCOSE 2011, 
204) 

1.2.3.2.1 

"Involve all 
personnel with 
knowledge and 
experience 
relevant to the 
decision" (INCOSE 
2011, 204) 

282 

The tool shall provide a list of 
recommended participants based on the 
decision category and the project 
organizational hierarchy chart 





1.2.3.2.2 

"Evaluate the 
consequences of 
alternative choices 
using the selected 
strategy and 
optimize the 
decision" (INCOSE 
2011, 205) 

283 

The tool shall support analysis of 
alternative choices through weighted 
ratings 







284 

The tool shall support simulation of 
decisions with impacts on cost, schedule, 
performance, and risk 





1.2.3.2.3 

"Make the 
decision, based on 
the relevant data 

285 

The tool shall rank the choices based on 
the results of the weighted ratings 


93 





Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






and inputs" 

(INCOSE 2011, 

205) 





1.2.3.3 

"Track the 

Decision" 

(INCOSE 2011, 
205) 

1.2.3.3.1 

"Record the 
decision, with the 
relevant data and 
supporting 
documentation" 
(INCOSE 2011, 

205) 

286 

The tool shall support documenting of the 
final decision and all relevant data and 
supporting documentation 





1.2.3.3.2 

"Communicate 

new directions 

from the decision" 
(INCOSE 2011, 

205) 

287 

The tool shall update budget, schedule, 
technical, and risk data based on the 
decision parameters 

1.2.4 

Risk 

Management 
(INCOSE 2011, 
215) 

1.2.4.1 

"Plan Risk 
Management" 
(INCOSE 2011, 
218) 

1.2.4.1.1 

"Define and 

document the risk 
strategy" (INCOSE 
2011, 218) 

288 

The tool shall provide a template 
documenting the risk plan which includes 
risk, issue, and opportunity management 







289 

The tool shall support execution of 
electronic risk boards 



1.2.4.2 

"Manage the 

Risk Profile" 
(INCOSE 2011, 
218) 

1.2.4.2.1 

"Define and 

document risk 

thresholds and 
acceptable and 
unacceptable risk 
conditions" 

(INCOSE 2011, 

218) 

290 

The tool shall provide a risk identification 
form that allows detailed documentation 

of risks 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







291 

The tool shall support user configurable 
thresholds for likelihood and consequence 
levels 





1.2.4.2.2 

"Periodically 
communicate the 
risks (and 
opportunities) 
with the 
appropriate 
stakeholders" 
(INCOSE 2011, 

218) 

292 

The tool shall auto-generate risk burn- 
down charts from the risk identification 

forms 







293 

The tool shall auto-generate various views 
to visualize the risk profile, including views 
that show all risks simultaneously from 
approval to close-out 



1.2.4.3 

"Analyze Risks" 
(INCOSE 2011, 
219) 

1.2.4.3.1 

"Identify and 
define risk 

situations" 

(INCOSE 2011, 

219) 

294 

The tool shall support development of 
candidate risks 







295 

The tool shall support tracking of watch 
items 





1.2.4.3.2 

"Analyze risks for 
likelihood and 
consequence to 
determine the 
magnitude of the 
risk and its priority 

296 

The tool shall auto-generate risk rankings 
based on the risk exposure (LxC and/or 

L+C) 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






for treatment" 
(INCOSE 2011, 

219) 







1.2.4.3.3 

"Define a 

treatment scheme 

and resources for 
each risk, including 
identification of 
person who will be 
responsible..." 
(INCOSE 2011, 

219) 

297 

The tool shall support selection of a 
treatment scheme (avoid, accept, control, 
or transfer) for each risk 







298 

The tool shall support identification of a 

POC for each risk, candidate risk, and 
watch item 



1.2.4.4 

"Treat Risks" 
(INCOSE 2011, 
219) 

1.2.4.4.1 

"Using the criteria 
for acceptable and 
unacceptable risk, 
generate a plan of 
action when the 

risk threshold 

exceeds 

acceptable levels" 
(INCOSE 2011, 

219) 

299 

The tool shall support development of a 
plan of action for each risk that is triggered 
by the risk thresholds 



1.2.4.5 

"Monitor Risks" 
(INCOSE 2011, 
219) 

1.2.4.5.1 

"Maintain a record 

of risk items and 
how they were 
treated" (INCOSE 

300 

The tool shall maintain the history of each 
closed risk 


96 





Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






2011, 219) 









301 

The tool shall support documentation of all 
relevant minutes, decisions, and artifacts 
for each risk, candidate risk, and watch 
item 







302 

The tool shall record progress against all 
risk milestones and footstones 







303 

The tool shall link each risk to the impacted 
tasks in the project schedule and translate 
the risk burn-down profile to the most 
likely, worst case, best case durations for 
each impacted task 







304 

The tool shall support calculation of a 
schedule risk analysis to any user defined 
tollgate or milestone 





1.2.4.5.2 

"Maintain 
transparent risk 
management 
communications" 
(INCOSE 2011, 

219) 

305 

The tool shall show all risk working groups 
and boards on the schedule 



1.2.4.6 

"Evaluate the 

Risk 

Management 

Process" 

(INCOSE 2011, 
219) 

1.2.4.6.1 

"Define, analyze, 
and document 

measures 

indicating the 
status of the risk 

and effectiveness 

of the treatment 

306 

The tool shall auto-generate summary 
views of the risk process, including 
effectiveness of risk treatment 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






alternatives" 
(INCOSE 2011, 

219) 









307 

The tool shall be capable of auto¬ 
generating an audit checklist to evaluate 
the Risk Management Process 

1.2.5 

Configuration 
Management 
(INCOSE 2011, 
228) 

1.2.5.1 

"Plan 

Configuration 
Management" 
(INCOSE 2011, 
230) 

1.2.5.1.1 

"Implement a 
configuration 
control cycle that 
incorporates 
evaluation, 
approval, 
validation, and 
verification of 

ECRs" (INCOSE 

2011, 230) 

308 

The tool shall provide a template for a 
configuration management plan 







309 

The tool shall provide a template for a 
change control process to include 
management of ECRs 







310 

The tool shall support execution of 
configuration control boards 



1.2.5.2 

"Perform 
Configuration 
Management" 
(INCOSE 2011, 
231) 

1.2.5.2.1 

"Configuration 
Identification - 
Identify system 
elements to be 

maintained under 
configuration 
control" (INCOSE 

311 

The tool shall document system elements 
to be maintained under configuration 
control 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






2011, 231) 







1.2.5.2.2 

"Configuration 
Control - Establish 
the configuration 
baselines and 

control baseline 
changes 
throughout the 
system life cycle" 
(INCOSE 2011, 

231) 

312 

The tool shall record all baseline data and 
artifacts associated with each system 
element under configuration control 







313 

The tool shall trigger a configuration 
control board for any baseline changes and 
document all relevant data, including the 
new baseline 





1.2.5.2.3 

"Configuration 
Status Accounting 
- Develop and 
maintain 
configuration 
control 

documentation 

and communicate 

the status of the 

controlled items to 
the project team" 

314 

The tool shall be capable of storing all 
configuration control documentation that 
can be accessed by the team but can only 
be modified by select personnel 
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Level 3 


Process (after 
INCOSE 2011) 


Level 4 


Activity (after 
INCOSE 2011) 


Level 5 
















1.2.5.2.4 






1.2.6 

Information 
Management 
(INCOSE 2011, 
237) 

1.2.6.1 

"Plan 

Information 
Management" 
(INCOSE 2011, 
240) 

I.2.6.I.I. 


Sub-activity (after 
INCOSE 2011) 

(INCOSE 2011, 
231) 


R# 


Requirement 


"Configuration 
Audits - Perform 
audits associated 
with milestones 
and decision gates 
to validate the 
baselines" (INCOSE 
2011, 231) 


"Supporting 
establishing and 
maintaining a 
system data 
dictionary..." 
(INCOSE 2011, 
240)_ 


315 


The tool shall be capable of implementing 
access controls for all CM documentation 


The tool shall trigger baseline configuration 
audits based on decision gates and 

316 milestones 

The tool shall auto-generate baseline 

317 configuration audit checklists 


318 


The tool shall provide an information 
repository 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 





1.2.6.1.2 

"Define system¬ 
relevant 
information, 
storage 
requirements, 
access privileges, 
and the duration 

of maintenance" 
(INCOSE 2011, 

240) 

319 

The tool shall support establishing access 
privileges for the information repository 







320 

The tool shall provide user configurable 
attributes for storage requirements that 
can be applied to each system element and 
across the system 





1.2.6.1.3 

"Define formats 

and media for 
capture, retention, 
transmission, and 
retrieval of 

information" 
(INCOSE 2011, 

240) 

321 

The tool shall support web-based access of 
data in the information repository 







322 

The tool shall support e-mailing of data in 
the information repository 







323 

The tool shall support capture of e-mailed 
documents into the information repository 





1.2.6.1.4 

"Identify valid 
sources of 

information" 

324 

The tool shall provide an attribute to 
indicate the maturity of any data 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






(INCOSE 2011, 

240) 









325 

The tool shall provide an attribute to 
indicate the source of any data 



1.2.6.2 

"Perform 

Information 
Management" 
(INCOSE 2011, 
240) 

1.2.6.2.1 

"Periodically 
obtain artifacts of 

information" 
(INCOSE 2011, 

240) 

326 

The tool shall query for updated 
documents based on the document 
delivery dates in the project schedule 







327 

The tool shall support sending of internal 
data update requests 





1.2.6.2.2 

"Maintain 

information 
according to 
security and 
privacy 

requirements" 
(INCOSE 2011, 

240) 

328 

The tool shall be capable of maintaining 
information at multiple levels of sensitivity 







329 

The tool shall support security controls for 
the information repository 





1.2.6.2.3 

"Retrieve and 

distribute 
information, as 
required" (INCOSE 
2011, 240) 

330 

The tool shall support queries of the 
information repository 







331 

The tool shall auto-generate information 
management reports based on user 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 








configurable parameters 







332 

The tool shall make the information 
repository accessible to stakeholders, with 
configurable permissions 





1.2.6.2.4 

"Archive 
designated 
information for 
compliance with 
legal, audit, and 
knowledge 
retention 
requirements" 
(INCOSE 2011, 

240) 

333 

The tool shall provide user configurable 
attributes for each artifact that designate 
archive requirements such as retention 
duration 





1.2.6.2.5 

"Retire unwanted, 
invalid, or 
unverifiable 

information 
according to 
organizational 
policy, security, 
and privacy 
requirements" 
(INCOSE 2011, 

240) 

334 

The tool shall support implementation of 
an information retirement schedule 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 

1.2.7 

Measurement 
(INCOSE 2011, 
242) 

1.2.7.1 

"Plan 

Measurement" 
(INCOSE 2011, 
245) 

1.2.7.1.1 

"Establish a 

measurement 
strategy" (INCOSE 
2011, 245) 

335 

The tool shall provide a template for a 
measurement strategy, which will be a 
subset of the project management plan 





1.2.7.1.2 

"Identify the 
measurement 

stakeholders" 
(INCOSE 2011, 

245) 

336 

The tool shall support identification of 
stakeholders for each measurement 





1.2.7.1.3 

"Identify and 
prioritize the 
information needs 

of the decision 

makers and 

stakeholders" 
(INCOSE 2011, 

245) 

337 

The tool shall allow for prioritizing, 
annotating, and adding identifiers for each 
data artifact 





1.2.7.1.4 

"Identify and 
select relevant 

measures that aid 

with the 

management and 
technical 
performance of 
the program" 
(INCOSE 2011, 

245) 

338 

The tool shall allow linking of data artifacts 
to specific measures 







339 

The tool shall suggest common measures 
used to support management and 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 








technical performance 





1.2.7.1.5 

"Define the base 
measures, derived 
measures, 
indicators, data 
collection, 
measurement 
frequency, 
measurement 
repository, 
reporting method 
and frequency, 
trigger points or 
thresholds, and 
review authority" 
(INCOSE 2011, 

245) 

340 

The tool shall support defining of user 
configurable attributes for each measure 



1.2.7.2 

Perform 

Measurement 

1.2.7.2.1 

"Collect, store and 
verify the data per 
plan" (INCOSE 

2011, 245) 

341 

The tool shall support recording of 
measurement data 





1.2.7.2.2 

"Process and 
analyze the data to 
obtain 

measurement 
results..." (INCOSE 
2011, 245) 

342 

The tool shall support multiple views of 
measurement data 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 







343 

The tool shall support common methods 
for processing measurement data 





1.2.7.2.3 

"Document and 

review 

measurement 

information 
products with 
measurement 

stakeholders and 

recommend 
actions" (INCOSE 
2011, 245) 

344 

The tool shall auto-generate charts that 
show collected measurement data 







345 

The tool shall auto-generate various views 
of the measurement data to identify trends 
and history 



1.2.7.3 

Evaluate 

Measurement 

1.2.7.3.1 

"Evaluate the 

effectiveness of 

the measures for 
providing the 
necessary insight 
for decisions" 
(INCOSE 2011, 

245) 

346 

The tool shall track the history of changes 
to measures 







347 

The tool shall make suggestions for 
changes to measure attributes based on 
historical results 





1.2.7.3.2 

"Evaluate the 
effectiveness, 
efficiency, and 

348 

The tool shall be capable of auto¬ 
generating an audit checklist to evaluate 
the Measurement Process 
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Level 3 

Process (after 
INCOSE 2011) 

Level 4 

Activity (after 
INCOSE 2011) 

Level 5 

Sub-activity (after 
INCOSE 2011) 

R# 

Requirement 






compliance of the 
Measurement 
Process" (INCOSE 
2011, 246) 







1.2.7.3.3 

'Assign corrective 
actions, if 
required" (INCOSE 
2011, 246) 

349 

The tool shall be capable of linking 
corrective actions to specific tasks in the 
project schedule 





1.2.7.3.4 

"Document and 
store all program 
measures and 

corrective actions 

in a measurement 
repository" 

(INCOSE 2011, 

246) 

350 

The tool shall store all measurement data, 
including corrective actions, in the 
information repository 
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